設定ファイルの中身や構成を見直す†
- ページ: BugTrack2
- 投稿者: henoheno
- 優先順位: 重要
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2005-03-06 (日) 09:57:17
- バージョン:
メッセージ†
PukiWikiの設定ファイル (pukiwiki.ini.php, rules.ini.php, default.ini.php, keitai.ini.php)、およびユーザーによるカスタマイズを意図している部分 (スキンファイルやプラグインの先頭部分) について、その表現方法や内容、構成に関する指針や話題をここにまとめましょう。
今までの問題として「全く見直しが入っていない」「統一感が無い」「グループ分けがあまり進んでいない」「どこを見たらいいかわかり辛い」「書き換えがし辛い」といった点があります。
ユーザーの設定値や重要な値には必要がなければ定数を用いる†
- (plus:BugTrack/25より)
Site-adminが決定した静的な設定に対して定数を使う方向性については、そのデータを(注・動的に)破壊・改ざんされるリスクをゼロにして安心したいという点と、従来の変数方式による実行時のメモリオーバーヘッドを極力減らしたいという点と、PHPアクセラレーターによるコンパイルキャッシュが効果を発揮するチャンスを増したい、といった種々の(贅沢な)希望がからんでいます。だから徹底的に見えるのでしょう。(※定数化による情報漏洩のリスクについては、変数やクラスにvar_dump()などを実行されるリスクと同程度だと思っています) -- henoheno 2005-02-27 22:41:29 (日)
// Spilitter of backup data (NOTE: Too dangerous to change)
define('PKWK_SPLITTER', '>>>>>>>>>>');
- 私が特に怖く思っていたのは上記の、バックアップファイルのデータとデータの境界を示す文字列が今までグローバル変数に格納されていたという点です(これを変更できればバックアップを破壊できます) -- henoheno
- そもそも、定数にできるほとんどは ini で設定する必要がないものとおもいます。よって、そういったものは ini から避けるぐらい（直接、pukiwiki.php もしくは init.php にあってもいいくらい。）でいいかとおもいます。 -- みこ
- あと、同じように共通的な定数で attach プラグインにある定数（最大アップロードサイズ）ですね。あれは制限もののため、他のプラグインが使う指標のためにも本体にあるべきかとおもいます。 -- みこ
- そうやっていくと、おそらく ini にのこるのは（ディレクトリの設定を除いて）変数になるはず。（関連：BugTrack2/41） -- みこ
- こんにちは :) 上記PKWK_SPLITTERなんかもそうですが、pukiwiki.ini.phpにあるべきでない要素を追い出せば、設定ファイルがもっとすっきりする、というのは全く同感です。 -- henoheno
- 変えられるとまずい重要な値だと、pukiwiki.ini.php の$adminpass や$non_list、init.php の$WikiName と$BracketName と$InterWikiName と$NotePattern なんかもそうですかね？
$adminpass は説明なくてもいいとして、もし$BracketName を一時的に書き換えられたら、通常の操作では編集不可の消せないページを作られそうです*1。
$non_list はサイトポリシーで、残りはどのPukiWiki サイトでも基本的に変わらない設定だが、改ざんされると、リンク表示の基準が変わるので困るものです。 --
- 「変更箇所が結構多いぞ」とか、「そこまでする必要あるのか」というツッコミは最低ありそう。 --
ユーザーが設定する部分の ON/OFF 指定は TRUE/FALSE より 1/0 であるべき†
// PKWK_READONLY - Prohibits editing and maintain via WWW
// NOTE: Counter-related functions will work now (counter, attach count, etc)
if (! defined('PKWK_READONLY'))
define('PKWK_READONLY', 0); // 0 or 1
厳格に言えば TRUE / FALSE で設定させて、値をチェックする側も === 演算子を使い厳格に判別させた方が(メモリの量や判別スピードなど)コンピュータにとっては良かろうと思われるのですが、 1 / 0 で指定する場合と比べ、管理者のタイプ量が違います。つまり手軽にON/OFFを切り替えられるかどうかに影響します。
このようにするためには、設定系の値に関しては、値を厳格に見過ぎないようにチェックする必要があります。
- そんなに頻繁に変更するだろうか？と考えると、私はTRUE/FALSE の方がより可読性があって良いと思います。 -- jjyun
- 可読性の面で私もTRUE/FALSE*2です．数値ですと0 or 1とかいいつつ2を入れてもおそらくエラー出ませんが，TRUE/FALSEならtypoに関しては何らかのエラーが出てきます． -- ELF
- プログラマじゃない人からすると、多分1|0よりもTRUE|FALSEの方がわかりやすいと思います。 -- okkez
- お、意外な反応ですね (^^; 私個人も、コードのクリンナップの際に TRUE or FALSE で厳格に書いた方が良いと考えていたため、一時は設定部分に関してもかなり厳格に書いていました。しかし一方で(TRUE or FALSE を設定部分に用いてしまうと)「チョコチョコonにしたり、offにしたりしながらPukiWikiの反応を見たい」場合に軽快さが失われてしまう欠点がある事に長らく悩んでいました。 -- henoheno
- そのバランスを取るために取ったのが、「設定の部分では 1 or 0 を使う」という方法です。別にhenohenoが突然勝手にやりだしたことではありません。今現在 $referer, $trackback, $nowikiname などの各種設定も 1 or 0 方式になっていますよね (^^; -- henoheno
- ということで、$referer, $trackback, $nowikinameなどについても全部 TRUE or FALSE 方式が良いとまで考えているのかどうか、もう一歩踏み込んだコメントを願います。関係ないけど TURE とか FASE なんてtypoは泣けますよね。 -- henoheno
- オリジナルの作成時には、henohenoさんが述べられているような目的が強かったと思います。しかしこれまで 0/1を真偽値として設定に使ってきたのは、上記のような規約が見えない状態だったため、メンテナーの方はオリジナルの設定ファイルの流儀に従ったものと考えていました。
より広く一般の人が使う現状では、修正のし易さからタイプする数を減らすした効率と、可読性を上げるのとどちらがより効率的かと考えた時には後者だと思います。 -- jjyun
- (どこかで話がでていたと思いますが) pukiwiki としてのコーディング規約 として今後どうあって欲しいか？と問われているならば、私は真偽値を扱う際には、それを表すものとして提供されているTRUE/FALSE を使うべきだと考えます。 -- jjyun
- 但し （言い逃れになっていますが）上記のものは変数名から対象が真偽値を扱う対象か判断できません。 isXXX といった変数名でもないので、修正の前には、対象が真偽値として扱ってよいものか、確認する必要があると思います。( 想像ですが...0/1 という値の他に今後 2 という値も取らせる運用を想定していたのかもしれない） そういった意味ではコメントがなくても内容の意味がわかる変数名や定数名であって欲しいとも思っていました。 -- jjyun
- 自分の場合「チョコチョコ(ry」ときは、*3二行*4書いておいて片方をコメントアウトするようにしています。こうすると、環境によっては非常に少ない操作で設定値を切り替えられるので軽快さが損なわれる等のデメリットは感じません。そもそも、「ちょこちょこ(ry」は開発者、もしくはスキルは無いが色々試してみたい人がやることなので、いわゆる素人さんが変更しやすいようにする必要は無いと思います。 -- okkez
- 0or1とTRUEorFALSEの比較としてちょこっと簡単なコードを書いたので貼っておきます。
ページが長くなるのでコメントアウトしてあります。 -- okkez
- 0 or 1を頑なに使わない(笑 ので頭が固いんだと思うのですが，)「チョコチョコonにしたり、offにしたりしながらPukiWikiの反応を見たい」がTRUE or FALSEでなぜできないのかがイマイチわかりません．説明できそうなら何らかの情報をいただけますか? -- ELF
- 正直どっちでもいいです。マニュアル(コメント)やドキュメントがしっかりしていれば (^^; *5 -- みこ
- ただ、ポリシーはそろえてほしいかも（ 0 or 1 なら条件文は == 0 / != 0 で見るのが基本） -- みこ
- では、わたしはこの辺で・・・ (^^;*6 -- みこ
- 今設定ファイルを見て思ったのですが，統一されていればみこさん仰るとおり? 「 define('PKWK_READONLY', 1); // 0 or 0」「 define('PKWK_READONLY', 0); // 0(disable) or 1(enable)」とか全部に値の意味があれば数値でもいい気もしてきています -- ELF
- 0/1で設定させる項目と、TRUE/FALSEで設定させる項目が混在してしまうのはよくないと私も思います。
タイプ量を減らすという理由より、全体の整合性を取るために0/1での設定にしているということなら納得です。*7 しかしこんなにコメントがつくとは予想外でした。 -- jjyun
- こんにちは :) okkez さんがコメントの中に書いている、型を判別する等号演算子(=== / !==) は、TRUE/FALSEを使うなら常識的に使って欲しいものなので、誤解していなければ話としては別件のようです。 -- henoheno
- というわけで、「管理者がON/OFFを操作する部分を 1/0 で統一する、ただしコメントなどで適宜意味合いを補うこと、また1がON(有効)、0がOFF(無効)であるという意味で用いること」、という感じでよろしいでしょうか。対象は設定ファイルと、ユーザーが設定する余地を残している部分(一部のプラグインやスキンの先頭)になります。それ以外の部分は、従来通り TRUE/FALSE で厳格にやるべきでしょう。また何かあればここにコメントして下さい。 -- henoheno
定数のネーミングルールを揃える†
- 最近追加しているものについては 'PKWK_' というプレフィックスを付けています。
- プラグインについては、ここまでの間にかなり修正を図っていますが PLUGIN_<plugin-name>_<subject> という形式に修正しています。プラグイン間でバッティングする可能性は残っていますが、その場合値が改ざんされることはなく、(定数の二重定義として)即座にエラーが出るでしょう。
PukiWikiは有志によって全体および一部がXOOPSに組み込まれていますが、どこでもありそうな定数を定義してしまうと、組み込み作業時に問題となることでしょう。
- 基本的にこの考え賛成です．プラグインもPKWK_PLUGINに(ようするにPKWK_つけたほうが)より問題は少ないですよね． -- ELF
- 厳密にやりすぎると今度は名前が長くなりすぎます(PukiWikiのコードが簡潔でなくなります)。どんな時に誰が困るのかを明確にした上で、現実的に可能な範囲で一石N鳥となるようにバランスを保とうと言うのみです。 -- henoheno
設定値のグルーピングをもう少しわかり易くできないか†
WikiNameを無効にする設定など。実際のニーズを掘り下げて、一緒にいじりそうな設定のそばに置けないだろうか?
- PukiWiki Plus! にて、検討中。ただし「そもそも設定ファイルにいらないだろう項目」や「デフォルト項目として用意しておけば不要になるであろう項目」を追い出した後ではないので今後も検討が必要か。 -- henoheno
rules.ini.php -- 消せる†
rules.ini.php は、その中身を全て pukiwiki.ini.php に移すことで不要にできそうです。
ちょっと確認: rules.ini.php が生まれた背景†
- cvs:rules.ini.php (1.1)
- BugTrack/476 において 2003年10月(PukiWiki 1.4) のころに、$str_rulesを機能させるべく pukiwiki.ini.php から分離。フェイスマークもこの時に分離さる。
- しかし、フェイスマークは現在 default.ini.php, keitai.ini.php に吸収されている。
コメント†
- 追いきれてないのですが，以前はpukwiki.ini.phpにあったものがなぜrules.ini.phpに分離したのでしょうか? というのはマージしたり分離したりってのが「メインメンテナーが変わって判断基準が変わったから」的なところは避けたい(もし変更するならこれを最後にしたい)と思うからです -- ELF
- お気づきとは思いますが、上に背景を書いておきました -- henoheno
- メインメンテナーの都合で作られたり消されているのかどうか、また根本的な対策が成されているかどうかもハッキリしない段階で仮定に基づいた前提と希望を言うべきではありません。このBugTrackでまさに挙げている通り、設定系は全く見直されていませんので、これで最後にしたいという期待が実現する保証はありません。 -- henoheno
- なるほどBugTrack/476について正しく理解できたと思います．はっきりしない段階での～言うべきではありません．も了解しました．以後気をつけます． -- ELF
デフォルト設定と、それを上書きできる仕組みが欲しい†
各種設定ファイルにデフォルトの設定が施されていたとして、ユーザーが別途(例えばUnixの/etcに)用意した定義ファイルをロードすると、デフォルト設定が一部上書きされた状態で起動する様にできないか。(※以前から要望アリ)
- BugTrack2/41から辿ってきました。WikiFarmの実現を楽にするために是非実現して欲しい機能です(でもこの場合は、/etc ではなく、それぞれのWikiのpukiwiki.ini.php が置かれている場所に格納されるものだと思います.) -- jjyun
- 設定を変更する可能性の高いものから分けていくという案を考えてみましたが、こちらの方がスマートですね :) -- Ratbeta
- 「別途用意した定義ファイル(例えば/etc)」としたのは、展開したPukiWiki本体とは全く別の場所であることも可能にしたいからです。例えばパッケージからインストールしたPukiWikiを新しいバージョンに更新した際に、影響を全く受けない場所です。 -- henoheno
- あぁ、意図がわかりました、設置方法にそういう選択肢があるのもいいですね。:) -- jjyun
PKWK_READONLYをPKWK_UTF8_ENABLEと同じように読み込み専用に†
- 存在自体でreadonlyにするべき。if (defined('PKWK_READONLY')) 読み込み専用。とする方が、改ざんに強くなる。 実行中にプラグイン側からも、読み込み専用に変更できる利点がある。未対応プラグインへの配慮として別の定数を新規に用意するのもいいと思う
file_writeあたりにそういう処理をいれれば、かなりセキュリティに強くなる。
if (defined('PKWK_READONLY') && (PKWK_READONLY) && (!defined('PKWK_SECURITY_READONLY'))) define('PKWK_SECURITY_READONLY',1);
if (defined('PKWK_SECURITY_READONLY')) 読み込み専用。とする
それを利用してセキュリティ用のプラグインを開発すればかなり攻撃・誤動作を防ぐことができるはず。 --
- 関連: BugTrack/744 --
コメント†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
