- 追加された行はこの色です。
- 削除された行はこの色です。
[[../]]
*任意のページごとの閲覧・編集制限 -- [[Ynak]] [#vafde73d]
#contents
**できること [#nb75034e]
任意のページに対する閲覧・編集・検索でアクセス制御を行う。
アクセス制御対象となるページは、以下のいずれかで決定できる。
-ページ名にある正規表現にマッチした場合
-ページ内容にある正規表現にマッチした場合
(具体例)
-××ページは全員が閲覧できるが、内容を編集できるのは○○だけ。
-△△ページは□□だけが閲覧・編集できる。
-○△ページは○○と□□が閲覧できるが、編集は○○だけ。
**設定ファイルの仕様 [#a08ac0a5]
pukiwiki.ini.phpに以下の項目を設定することで、
既存・新規作成ページに対するアクセス制御を行うことができる。
-ユーザ定義
-認証方式種別
-閲覧認証フラグ
-閲覧認証対象パターン定義
-編集認証フラグ
-編集認証対象パターン定義
-検索認証フラグ
***ユーザ定義 [#q9906b10]
アクセス制御で使用するユーザとパスワードを設定する。
// ユーザ定義
$auth_users = array(
'foo' => 'foo_passwd',
'bar' => 'bar_passwd',
'hoge' => 'hoge_passwd',
);
***認証方式種別 [#k1476f05]
××認証対象パターン定義で定義したパターンがどこにあったら、
マッチしたことにするのか、を設定する。
※今回からページ内容によるアクセス制御に対応した。
// 認証方式種別
// pagename : ページ名
// contents : ページ内容
$auth_method_type = "contents";
***閲覧認証フラグ [#z874fa60]
閲覧認証によるアクセス制御を行うかどうか設定する。
不要な場合はオフにすればパターンマッチングを行わないので、性能劣化を防止できる。
// 閲覧認証フラグ
// 0:不要
// 1:必要
$read_auth = 1;
***閲覧認証対象パターン定義 [#z1848dd8]
閲覧認証をかけるページを決定するための正規表現パターンを設定する。
マッチしたページに閲覧認証をかける。
カンマ区切りで複数ユーザを書いても良い。
// 閲覧認証対象パターン定義
$read_auth_pages = array(
'/ひきこもるほげ/' => 'hoge',
'/(ネタバレ|ねたばれ)/' => 'foo,bar,hoge',
);
***編集認証フラグ [#l75b2298]
編集認証によるアクセス制御を行うかどうか設定する。
不要な場合はオフにすればパターンマッチングを行わないので、性能劣化を防止できる。
// 編集認証フラグ
// 0:不要
// 1:必要
$edit_auth = 1;
***編集認証対象パターン定義 [#s48f4bb2]
編集認証をかけるページを決定するための正規表現パターンを設定する。
マッチしたページに編集認証をかける。
カンマ区切りで複数ユーザを書いても良い。
// 編集認証対象パターン定義
$edit_auth_pages = array(
'/Barの公開日記/' => 'bar',
'/ひきこもるほげ/' => 'hoge',
'/(ネタバレ|ねたばれ)/' => 'foo',
);
***検索認証フラグ [#jc7b64ea]
検索時にも閲覧認証と同等のアクセス制御が必要かどうか設定する。
どちらの場合も、ページ名は公開情報なので検索対象となる。
// 検索認証フラグ
// 0: 閲覧が許可されていないページ内容も検索対象とする
// 1: 検索時のログインユーザに許可されたページのみ検索対象とする
$search_auth = 0;
***設定例の解説 [#pd05d4f5]
上の例では
-「Barの公開日記」は、誰でも閲覧できて、barだけが編集できる。
-「ひきこもるほげ」ページは、hogeだけが閲覧・編集できる。
-「映画紹介～ネタバレ注意」ページは、foo, bar, hogeの三人だけが閲覧できて、かつ、編集はfooだけが可能。
のような設定となる。
かなり強引にUNIXっぽく表現すると、こうなる。
アクセス権 ユーザID グループ ページ名
-rw----r-- bar なし Barの公開日記
-rw------- hoge なし HogeOnly
-rw-r----- foo hoges 映画紹介～ネタバレ注意
※グループhogesには、barとhogeが所属するとする。
**本体の改造 [#x8da611f]
PukiWiki1.4rc2(20030529版)をベースにする場合は、以下を改造する。
((長いので別ページで。))
-[[./ja.lng]]
-[[./en.lng]]
-[[./func.php]]
***pukiwiki.ini.php [#l09a39d1]
設定ファイルの仕様で紹介した項目を追加して、適切な設定を行う。
すでに存在している$edit_auth, $edit_auth_usersの設定は削除するか、
コメントアウトすること。
**プラグインの改造 [#b5bf2187]
アクセス制御する仕組みは用意したが、
実際にページにアクセスするのはすべてプラグインである。
よって、プラグインで以下の関数による事前チェックを行うように改造する必要がある。
***アクセス制御用の関数仕様 [#fdd50fbf]
-check_readable($page, $auth_flag=true, $exit_flag=true)
--閲覧することができるかチェックする。
--今のところread_authと全く同じ。内部でread_authのみを呼び出している。
-check_editable($page, $auth_flag=true, $exit_flag=true)
--編集することができるかチェックする。
--edit_auth＋凍結などのチェックをする場合。
-read_auth($page, $auth_flag=true, $exit_flag=true)
--閲覧権限があるかチェックする。
-edit_auth($page, $auth_flag=true, $exit_flag=true)
--編集権限があるかチェックする。
~
|引数 |説明|
|$page |ページ名文字列|
|$auth_flag |true: 現在のログイン状態で認証NGであれば、BASIC認証発動(デフォルト)|
| |false:現在のログイン状態で判断するだけ|
|$exit_flag |true: 認証NGの場合、check_xxxable関数側でNG画面に遷移する(デフォルト)|
| |false:認証NGの場合でも、戻り値falseで戻ってくるだけ|
~
|戻り値 |true: 認証OK|
| |false:認証NG|
-get_source, file関数を使用している全てのプラグインで、
以下の関数による事前チェックを行うように改造しなければ、
そこが''セキュリティホール''になるので注意！！
-使わないプラグインはpukiwiki/plugin/disableディレクトリを作って
そこに入れておくなどして、無効化すると良い。
-check_xxxxable系とxxx_auth系の使い分けは、特に問題がなければ、総合的な
観点で読めるか書けるかを判断しているcheck_xxxx系の方を利用する方がよいと思う。
-第2、第3引数のデフォルト値は既存プラグインとの互換性のために用意している。
今後プラグインを実装する場合は明示的に指定した方がよいと思う。
***要改造プラグイン一覧 [#nb9236e1]
この改造に伴って一緒に改造する必要があるプラグインの一覧を以下に示す。
Ynakの環境で単にgrep -lE '(get_source|file)' pukiwiki/plugin/*.phpした結果+read.inc.phpなので漏れがあるかもしれない。
このうち少なくともedit, read, edit, backup, diffは絶対に改造する必要がある。
※改造したものからリンク先に改造方法を書く、ということでよろしければご協力お願いします。
-[[./amazon.inc.php]]
-[[./article.inc.php]]
-[[./attach.inc.php]]
-[[./backup.inc.php]]
-[[./bugtrack.inc.php]]
-[[./calendar2.inc.php]]
-[[./calendar_edit.inc.php]]
-[[./calendar_read.inc.php]]
-[[./calendar_viewer.inc.php]]
-[[./comment.inc.php]] →編集は×でもコメントは追加していい、という場合は改造不要。
-[[./counter.inc.php]]
-[[./deleted.inc.php]]
-[[./diff.inc.php]]
-[[./edit.inc.php]]
-[[./filelist.inc.php]]
-[[./freeze.inc.php]]
-[[./include.inc.php]]
-[[./includesubmenu.inc.php]]
-[[./insert.inc.php]]
-[[./interwiki.inc.php]]
-[[./list.inc.php]]
-[[./ls.inc.php]]
-[[./ls2.inc.php]]
-[[./map.inc.php]]
-[[./memo.inc.php]]
-[[./online.inc.php]]
-[[./paint.inc.php]]
-[[./pcomment.inc.php]]
-[[./popular.inc.php]]
-[[./read.inc.php]]
-[[./recent.inc.php]]
-[[./rename.inc.php]]
-[[./ref.inc.php]]
-[[./rss.inc.php]]
-[[./rss10.inc.php]]
-[[./showrss.inc.php]]
-[[./source.inc.php]]
-[[./template.inc.php]]
-[[./touchgraph.inc.php]]
-[[./unfreeze.inc.php]]
-[[./versionlist.inc.php]]
-[[./vote.inc.php]]
-[[./yetlist.inc.php]]
**推奨運用方式 [#tf70d0ad]
Ynakのところで運用している方式と、その説明ページの内容をコピーしておく。
→[[./推奨運用方式]]
**注意点 [#s838ea07]
-閲覧認証をかけたページは、編集認証も必須。
--でないと、「編集」リンクから内容が読めてしまったり、挙動が怪しくなったりする。((UNIXでも、rw-(閲覧認証＆編集認証の同時設定)はOKだけど、 -w-(編集認証のみ)はいろいろと問題が発生するのと似てる。))
--編集可能ユーザは、閲覧可能ユーザのサブセットとなるように設定すること。
-edit_auth_pagesなどのvalue部分と、BASIC認証のユーザ名の比較をpreg_matchで行っているので、あるユーザIDのサブセットとなるようなユーザIDがあるとややこしくなる。
--例えば、'hogefoobar'というユーザIDがあって、このユーザだけが編集できるようなページを以下のように設定する状況を考える。
$edit_auth_pages = array(
'/Secret/' => 'hogefoobar',
);
--ここでもし、'hoge'、'foo'、'bar'というユーザIDが存在していれば、そのいずれかのユーザIDでBASIC認証を突破すれば、このSecretページにアクセスできてしまう。
--とりあえず、pukiwiki.ini.phpにユーザID設定をする人が気を付ければ良いので、気にしていませんが、良い回避法があれば修正してください。
-通常の設定ではwikiディレクトリ配下のファイルは直接URL指定でアクセス可能であるため、
ApacheのBasic認証などを利用して、直接アクセスを防止しておかないといけない。
--たとえば、下記のような.htaccessを配置すると良い。
AuthUserFile /usr/local/apache/htdocs/basic/.htpasswd
AuthGroupFile /dev/null
AuthName "PukiWikiData"
AuthType Basic
require valid-user
--詳しくはApacheなどのドキュメントを参照のこと。
*コメント [#r1236f33]
-できるだけ1.4の設計思想(？)を優先して、きれいにまとめてみたつもりです。 -- [[Ynak]] &new{2003-05-20 (火) 23:28:16};
-pcommentもセキュリティホールになりますね。改造しないと。 -- [[Ynak]] &new{2003-05-22 (木) 00:09:00};
-あと、メイン機能系では添付ファイルのアクセス制限に未対応ですが、これをやるのはかなりの大工事になりそうですね。ページごとにサブディレクトリを作って、とかやればいいのかな？ -- [[Ynak]] &new{2003-05-22 (木) 00:10:39};
-ページ名による制御対象のページ指定に対応したので、一新してみました。しかしアレですね、ページ名の階層が深くなると、#recentの出力が鬱陶しくなるという弊害があるんですね。皆様すみません。 -- [[Ynak]] &new{2003-06-06 (金) 01:43:32};
-すばらしいですね。是非本家に取り入れて欲しい機能です。 -- [[puchi]] &new{2003-06-06 (金) 13:21:27};
-ありがとうございます。BugTrack/370で要望を出してみたところ、シグネチャ変更はまずいとのことなので(そりゃそうですね)、現在のCVS版と互換性を実現してみました。 -- [[Ynak]] &new{2003-06-07 (土) 00:15:48};
-私の方での利用形態では一通り試して特に問題は見つかりませんでした。edit_authを独自に使用されているプラグインと連携してどうなるかですが、どのプラグインでedit_authを使用されているかわからなかったので確認できていません。 -- [[Ynak]] &new{2003-06-07 (土) 00:30:11};
-ソース差分をチェックしただけで検証をしていないのですが、sourceプラグインも参照権限のチェックが必要ではありませんか？ -- [[にぶんのに]] &new{2003-07-06 (日) 22:21:30};
-まだ、使いはじめたばかりでわからないこといっぱいなんですが、passwordをmd5にするにはどうしたらいいんでしょう? -- [[merlin]] &new{2003-07-15 (火) 16:19:54};
-md5というプラグインが1.4で追加されているのでそれを使ってみて下さい。使い方はマニュアル/プラグインに書いてありますので。 -- [[にぶんのに]] &new{2003-07-15 (火) 23:54:08};
-ユーザ定義のところにmd5にしたパスワードを書きたいのですが、認証時にエンコードしてくれるか?ということなんですが ... -- [[merlin]] &new{2003-07-16 (水) 01:58:03};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
