Pukiwikiは便利なので使っている団体も多いと思う。

そしてPukiwikiにはBasic認証がついているし、一応認証をかけることもできるのだが、これは人数などによってはパスワードの管理がめんどくさいこともある。

そこで、Pukiwikiを適当に改造して独自の認証で特定の条件を満たしたもののみが見ることができるWikiを作ることを考える。前提として、最低限PHPでプログラミングができる程度の知識は必要となる。

まず、独自の認証を追加するかどうかに関わらず、.htaccessが有効になっていることを確認する。Wikiのディレクトリが/wiki/とした時に、/wiki/data/以下のファイルとかに直接アクセスされるようでは認証もへったくれもない。こういう外部のアプリケーションを展開するときは.htaccessが有効になっている方が安全だが、どうしても.htaccessが有効にできない（セキュリティ上の理由がApache以外のウェブサーバーなど）ときは、それを適切に設定する。例えば/wiki/に設置した場合なら/wiki/data/につないだ時にエラーが出れば問題ない。AllowOverRideの設定を修正するわけだが、わからない場合は適当に調べること。

さて、それが完了してかつpukiwiki.iniの初期設定が終わったらPukiwikiを改造する。

Pukiwikiのフォルダの lib/auth.php を開くと色々関数が出てくる。read_authとedit_authを見て、これを自分が望むように編集する。概ね、見せて良い相手の場合はreturn true;とかして、そうではない場合は望むエラーメッセージを表示してexit;するとよいようだ。もともとはbasic_authを呼び出すようになっていて、問題がある場合は中でエラーメッセージを表示するようになっているが、このエラーメッセージ表示の部分をコピペしても最新の更新とかその辺りの一覧が見えてしまってよろしくないし、何より今からログインしたい人宛のリンクがなくて不便。そのため、ログイン画面にheader(‘Location /login.html’);とかで飛ばしてexit;するのが一番よいだろう。こういう内容でread_authとedit_authを書き換える。

……なのだが、PukiwikiにはBasic認証とは別の認証方法をとるページがあって、そういうページにはアクセスできてしまう（もちろんpukiwiki.iniで書いたパスワードを入力する必要はあるので、実際的な問題はないはずだが）。

その対策のため、read/writeなど細かく権限を分ける必要がないなら認証のコードをindex.phpの冒頭に書いてしまうのもバッドノウハウとして有効だと考えている。どうせ独自認証はCookieとSQLが使えれば充分であることが多いと思うので、index.phpの冒頭でSQLに接続、Cookieの中身を検索して閲覧させて問題ないようならスルー、そうでないなら適当なページにリダイレクトしてexit;してしまうなど。

.htaccessをみるとわかるが、Pukiwikiに最初から添付されている画像などのファイルのほかはindex.php以外は.htaccessによってアクセスを禁止されている。そのため、index.phpにだけ認証に必要なプログラムを書き込むことで全体に対して接続を禁止できる。書き込み権限を分けたいのであれば、lib/auth.phpのedit_authだけ書き換えればよい。ページ名は来ているようなので、ページごとに権限をわけることはできるだろう。

具体的なPHPのコードについてはこのページでは言及しない。もし連携を取りたい他のログインしすてむがPHPで書いてあるならそれのライブラリをincludeするなり必要な部分だけコピペするなり、あるいは$_SESSION等を自前でSQLに突っ込むことで認証するなりすることもできるだろうし、他の言語で書いてある場合はその言語が善きに計らってセッション管理してくれているのをまずはSQLにセッションIDと対応するユーザー情報を書き込むように書き換えるところから始めないといけないかもしれない。PHP側でセッションを新たに読みだしてSQL文をひとつふたつ書いてやるのがいいかもしれないし、連携先で使っているライブラリを流用するためにパイプで繋いでやるほうが楽かもしれない。

# それにしても、Pukiwiki、なんとなくこれぐらいならみんな使えるよね的な雰囲気で使わされることも多くあるが、Pukiwikiの編集はプログラミングをしない層にとっては全然そんなことないと思うのだが。少なくともパソコンというものにある程度慣れていてPukiwikiが使える層にとっては非常に便利だからそういう場合はあえて変更する必要もないと思うが、そうではない場合は別なシステム、あるいはWYSIWYGな編集を実現するプラグインを検討する必要もあると思う。管理者の負担は増加するが。