Pukiwikiを遠隔ロックする機能†
- ページ: BugTrack2
- 投稿者: フォルグロス
- 優先順位: 普通
- 状態: 提案
- カテゴリー: 本体新機能
- 投稿日: 2007-03-10 (土) 11:45:38
- バージョン: 1.4.7
メッセージ†
掲示板系のCGIが「荒れる」というのはよくあることですが、全体がBBS状態のPukiwikiが荒れるとなるとえらいことです。
もし「あっ！荒れてる！」と思ったとき、会社、学校、電車の中、座敷牢からでも気軽にPukiwikiを遠隔ロックする方法を取り付けてはどうでしょうか。
試作品はPukiWiki改造/pukiwikiを遠隔ロックするです。
試作品の機能は２つです。
- 管理者パスワードがあれば、どこからでもPKWK_READONLYフラグを立てられます。
- 同じ方法で「カバー機能」を取り付けました。readプラグインが「しばらくお待ち下さい」系の言葉しか返さなくなります。
経緯はofficial:欲しいプラグイン/285です。
試作品は、本体への変更が明らかにおかしな場所に行われてます。（pkwk/lib/pukiwiki.php内でdefine定義やらPKWK_READONLY定義やらやってます。）
ただ、index.php内にif文をおきたくないし、かといってpukiwiki.ini.phpが読み込まれてからPKWK_READONLYを定義しても遅いようなので、とりあえずこの位置におきました。
これまた、使い方がさっぱり書いてなかったので追記します。
簡単に言って今回やっていることは、フラグファイル（２つ）の定義と、フラグが立っているか調べて特定の動作をする。あとはフラグファイル自体の操作の３アクションです。
- 定義
- フラグファイルとして使用する２つのファイルを定義します。
- フラグが立っていたら特定の動作をする
- READONLYする
- (pukiwiki_root)/easylock_readonly.lockファイルをフラグファイルとして、このファイルが存在すればdefine(PKWK_READONLY,1);します。
- カバーをかける
- 同じくeasylock_cober.lockで、read.inc.phpを呼び出したときこのファイルが存在すれば、get_sourceするよりも早く常に固定文字列を返します。
- リモートからロックファイルをいじる仕組み
- index.php?cmd=easylock形式でプラグインを呼び出すと管理人パスワードとフラグファイルの操作を尋ねられます。ログイン後は、フラグファイルをtouchかunlinkして報告するだけです。
- カバーをかける実装方法はいくらでもあるかも知れません（.htaccessに勝手に１行付け加えてbasic認証にする、index.phpのパーミッションを変える、get_sourceが常に空文字を返す、.htaccessでDirectoryIndex index.htm index.phpなどを定義して、カバーを掛けたいときだけindex.htmを自動作成、管理者はindex.php（ファイル名変更しておくとなおよし）に直行する等）が、一番簡単で効果絶大っぽそうなところとしてread.inc.phpを選びました。カバー機能は「荒れているとき、wikiを読みにきてくれた人に迷惑をかけない」ためのものと考えているので、read.inc.php以外の手段でわざわざ隠された中身を見ようとする人まで拒絶する必要性は薄いと考えています。（いちおうREADONLYなのでなにもできません。）
- カバーとREADONLYは別々のフラグで別個に動作します。READONLYにはするけどカバーをかけない、という動作は可能です。ただし、カバーだけかけてREADONLYにしない、というのは結局荒らされるので、easylockプラグイン内にその選択肢を用意していません。
- pkwk_login()に依存：そういえばそうですね。試作は動いてた気がしますが。ちょっと見てみます。
- 管理者パスワードが正しいかどうかを試行できる：今回は「荒れているとき、wikiを読みにきてくれた人に迷惑をかけない」ところが主眼ですので、正直そこは観点にありませんでした。
- BugTrack2/217を導入してもらえば試行があっても気づけるかと思います。
- でもそれを観点に含めてもいいですよね。せっかくなら。
- パスワード抜き取り試行の件ですが、管理者パスワードではなくREADONLY化専用のパスワードを使うようにするのはどうですか? -- ぃぉぃぉ
- と思ったけど、凍結でもなんでも、管理者パスワードの試行は可能か。それと何か違うんですかね? -- ぃぉぃぉ
- 凍結でもなんでも、管理者パスワードの試行は可能か。：いいえ、henohenoさんの言うとおりREADONLY化した以降は、たとえパスワードが正しくても認証失敗になりますので、試行することが無意味になります。 -- フォルグロス
- それと何か違うんですかね：ということで、試行しても無意味になるという点が違います。専用のパスワードを使うというのも案としてはアリと思いますが、あちこちにパスワードが分散するのもよくないので、可能な限り別の方法を模索するほうがよいと思います。いまのところ私も特に思いついてません。ただ、ベストな案がないからと言ってロック機構を実装しない危険性（→その結果、荒れても非常停止できない）と、非常手段としてベストではない方法であっても実装する危険性（→その結果、遠隔ロックパスワードを試行が可能である。パスがばれた場合には荒れても非常停止できない）では、機構があるメリットのほうが私は大きいと思います。*3 -- フォルグロス
- Pukiwiki2の談義に「フレームワークの機能をなるべくプラグイン化する」という話があったようなうろ覚えなのですが、今回の試作品はPKWK_READONLYをiniファイル直指定から動的設定に出すという野望も若干混じってます。 -- フォルグロス
- 前半分と後ろ半分の関係が解っていないのですが・・・前半分については、ライブラリと化す(lib/xxx.php)意味なら同意できるのですが、plugin/xxx.inc.php に置く意味が良くわかりません。後半部分、PKWK_READONLY (BugTrack/744) がコンパクトな実装であるために、拡張したいと思われているのだと思うのですが、一旦defineしたらもう変更できない、というPHPの定数の性質も考慮した実装であるため、内容によっては安心感が犠牲になります。 -- henoheno
- PukiWiki2のページを読んできましたが、プラグイン化するという話は見当たりませんでした。勘違いだったようですいません。試作品のほうも、既にPKWK_READONLYが定義されていればそれを解除するような機能は（できませんが*4）ついてません。 -- フォルグロス
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
