recentプラグインのリミッター†
- ページ: BugTrack2
- 投稿者: henoheno
- 優先順位: 普通
- 状態: 完了
- カテゴリー: プラグイン
- 投稿日: 2005-07-13 (水) 22:32:46
- バージョン: 1.4.6_rc
二度目以降は、HTMLのコメント文のみを出力します。このリミッターはrecentプラグインをいずれかの場所に数十個列挙された時のダメージを1倍にするために追加したものです。
メッセージ†
(開発談義 より移動)
- 1.4.6rcを試しているんですが、recentを表示しているページでMenuBar側のrecentが消えたのでビックリしました。何故recentを一度しか表示できないというリミッターが追加されたのでしょうか。キャッシュを持つrecentは制約を掛けるほど重いとは思えませんが。 -- にぶんのに
- 1.4.6rcにてMenuBarとRightBarにrecentを書いた。
自作スキン/OrangeBoxではRightBarにrecentが表示され、MenuBarには表示されなかった。
自作スキン/GSではその逆でRightBarには表示されず、MenuBarに表示された。 -- hirokasa
- お試しありがとうございます ;) その通りです。recentプラグイン(cvs:plugin/recent.inc.php (1.14) )は二度目からHTMLのコメント文のみを出力します。また、MenuBarは現状本文の後に評価されますから、MenuBarと本文の両方にあった場合はそうなるでしょう。このリミッターはMenuBarと本文の両方に一つづつ書いた場合については想定していませんが、MenuBarまたは本文に数十個列挙された時のダメージを1にするために追加したものです。hirokasaさんの言われているのもrecentプラグインの実行順に依存するものでしょう。HTMLのソースをrecentで検索すれば、コメントが見つかるのですぐに解ると思います。本文とMenuBarで一度づつ出力させたいならば、これを踏まえてもう少し改造するのが良かろうかと思います。 -- henoheno
- 要は「いたずら避け」です :) -- henoheno
- recent(): You already view changesですね :) -- hirokasa
- あの (^^; だからイタズラ避けが誤爆していると言っています。このロジックが加えられた意図は良くわかりませんが、真偽判定でなくincludeの様な呼出回数のリミッタをチェックするロジックへの変更を希望します。 -- にぶんのに
- リミッターを加えた意図は、recentプラグインを数十個列挙された時の処理時間や、転送量に対するダメージを無くするためのものです。呼び出し回数を例えば「2回まで」とした場合でも、#recent(100)を二つ置くいたずらが可能です。趣旨はご理解いただけましたでしょうか (^^; そういえばinludeプラグインも、同じコンテンツの多重インクルードはできません。includeの呼び出し回数リミッター(4ページまで)は、異なるページを無数にincludeさせるいたずらを防止するためのものです。 -- henoheno
- いいえ、依然として。 #recent(100) は呼び出し回数ではなく$maxshowの設定で解決すべき別問題でしょう。 列挙されればどのプラグインであっても同じ問題が発生します、本質的でないですね。100件*2のrecentは約60Kで処理時間は１秒未満です。ダメージが大きいですか？ なお質問箱3のtracker_listは同じく60K程ですが２秒以上掛かりますが、リミッタなしです。転送量が問題なら、編集して長文を貼り付けた方がお手軽ですがリミッタは掛かってないですね。 includeの件は無限ループの抑止が本質であって、同じコンテンツを複数表示させないのは、余禄にすぎません。 とまぁ、理由はいろいろあります。ところで私は実際にrecentを２つ置いてたんですが、これ「いたずら」だったんですかね？ (^^; -- にぶんのに
- メニューには最近の５件、それ以降はページに過去１００件と言った使い方をしていましす。「何回表示されればいたずらか？」と言う表示回数の指定は設置者が記述できるような仕様を希望します。 -- Yoshii
(開発談義 より移動 ここまで)
- うむ。今回にぶんのにさんはMenuBarで実行されることを想定していた二度目のrecentプラグインの呼び出しが不発に終わる様になったのがご不満の様ですね (^^; まずはrecentプラグインを単純に列挙(例えば数十個起動)される事でサーバーやユーザーがダメージを受ける可能性を完全に無くしました。それが現在です。それを踏まえて、何らかのニーズがあって穴を空けたいと言うのであれば、その通りに実装するのが良いでしょう。この場合、2回までの実行を許すのではなく、MenuBarで一回だけ、本文で一回だけ実行を許す様にすべきです。またその際は、Yoshiiさんが触れられている様に、recentに与える引数の数などもページの種類ごとに制限できても良いでしょう(単純な回数制限ではこのような細かいことができません)。そこまではよろしいでしょうか。 -- henoheno
- よくないです。んー、ご不満とかって書かれると駄々こねてるみたいで困っちゃいますが。なんかどうにも話が噛み合いませんな :(
recentによる処理時間・転送量の極端な増加を抑止する事、それ自体は消極的に肯定します。
ただその実現方法が現状の「完全に無くす」はやり過ぎだと言っています。
そして「MenuBar/本文で一回だけ」というのも機能過多／より優先してリソースを裂くべき事項はある筈、という事で反対です。
「ページ毎に引数の制限」に至っては、手段が目的化しているように思えます。
- recentの連続実行によって問題が発生した事実は寡聞にして知りません。
徹底的な対処より、そこそこ有効・融通の利く・早く実装できる対処が良いと考える次第です。
その対処の例として呼び出し回数による制限を挙げました。 -- にぶんのに
- それで、そこまで困っているデザインというのはどんな感じになっているのでしょうか? Yoshiiさんのように概要を教えていただけるともう少し具体的にイメージできると思うのですが。 -- henoheno
- 個人用メモのWikiでMenuBarにrecent20件とFrontPageにrecent5件置いてます。FrontPageのrecentは携帯からアクセスするとき良く使います。 -- にぶんのに
- なるほど、FrontPageの方の使い方は興味深いです。その状態でデスクトップから見た場合、デスクトップで使わない方しか残らず、デスクトップから期待する方が消えてしまうわけですね。 -- henoheno
- 納得いただけたかどうかはわかりませんが、一例として修正案を挙げておきます。検討のほど、よろしぅ。 -- にぶんのに
--- recent.org.php Fri Jul 08 02:28:25 2005
+++ recent.inc.php Fri Jul 15 22:28:02 2005
@@ -12,6 +12,9 @@
// Default number of 'Show latest N changes'
define('PLUGIN_RECENT_DEFAULT_LINES', 10);
+// Limit number of executions
+define('PLUGIN_RECENT_EXEC_LIMIT', 3);
+
// ----
define('PLUGIN_RECENT_USAGE', '#recent(number-to-show)');
@@ -22,7 +25,7 @@
function plugin_recent_convert()
{
global $vars, $date_format, $_recent_plugin_frame;
- static $done;
+ static $execute_cnt = 1;
$recent_lines = PLUGIN_RECENT_DEFAULT_LINES;
if (func_num_args()) {
@@ -34,8 +37,9 @@
}
}
- // Show only the first one
- if (isset($done)) return '<!-- #recent(): You already view changes -->';
+ // Control frequent execution
+ if ($execute_cnt > PLUGIN_RECENT_EXEC_LIMIT)
+ return '<!-- #recent(): You called me too much -->';
// Get latest N changes
if (file_exists(PLUGIN_RECENT_CACHE)) {
@@ -74,7 +78,7 @@
// End of the day
if ($date != '') $items .= '</ul>' . "\n";
- $done = TRUE;
+ $execute_cnt ++;
return sprintf($_recent_plugin_frame, count($lines), $items);
}
- 運用事例を伺って、困り具合が解りましたのでそれぞれのニーズをかなえるべく(今)検討します :) -- henoheno
- うーん 自作スキン/GS は $menubar2 という設定によって RightBar というページ名を設定させる様にしていて、Orangeboxはスキンにハードコードしてあるのか・・・ -- henoheno
- ああ、現状では「MenuBar(等)を」「menuプラグインが実行している」事のいずれも検知できないのだったっけな・・・ XD -- henoheno
- cvs:plugin/recent.inc.php (1.15) 上記パッチの方向で実行回数制限となる様に修正しました。デフォルトの実行回数は２回までです(少し厳し目です) -- henoheno
- 細かくてすいませんが (^^; 上記パッチでは(2回まで、ではなく)3回までとされていますが、その場合の利用形態(どんなニーズを予想されたか)を教えて下さい。 -- henoheno
- 対応お疲れ様です。設定の根拠ですがスキンによっては左右Menuがあるので、本文加えて３つです。私自身は２でも構わないのですが、リミッターがある事に意味があるのであって、２でも３でも大差はないという考え方です。誤爆が発生すると原因が俄かに分かり難い事もあって、であれば、誤爆が起きにくい数がよかろう、と。 -- にぶんのに
- cvs:plugin/recent.inc.php (1.16) なるほど。recentのメッセージをHTMLのコメント文の中に隠したのは工夫のつもりであったのですが、逆に状況が解り辛くなってしまっているというのも問題だったのですね。その点を修正しました。つまり、従来のプラグインと同様に、エラーメッセージを明確に出力する様に修正しました。(その他、不要なインクリメントを止めさせる修正) -- henoheno
- おぉ・・・cvs:plugin/recent.inc.php (1.15)入れました。('PLUGIN_RECENT_EXEC_LIMIT', 2)がデフォルトですか。自作スキン/GSはでは3にしないと・・・ですね。( -- hirokasa
- お疲れ様です。MenuBarが２つあるスキンに関して、リミッターを3にしなければならないという事はないと思います。２箇所のメニューバーと本文の三箇所にrecentを設置しなければ困りませんが、そのような運用形態がそう発生するとは思えません。仮にそうしたいのであれば、任意でこの設定を拡大すると良いのではないかと思います。 -- henoheno
- やはりもっときびしくリミッターをかけないと駄目でしょう。とんでもないことができる --
- (つづき）とんでもないことができる方法を発見してしまった。悪者が気づかないうちにリミッターをより厳しくしておいて欲しい。メニューに複数設置するような人は自己責任で改造するのがよかろう。あまり一般的に意味のあることとも思えないので。 --
- こんにちは。例えばそれが脆弱性やDoSに関する話題なら、「ここ」に「あいまい」に書く必要はありません。具体的に書くか、黙ってDevelopers Teamに連絡して下さい。なおrecentプラグインに限らず、全ての機能について、随分前から、不要な/安易な/不明確な資源の浪費をさせない方向で進んでいます :) -- henoheno
- 凍結ページにしか設置できないようにするというのはどうでしょう？*1たしかupkさんところのphpinfo()を表示するプラグインがそんな感じだったかと。 -- okkez
- 原因が分からないのに対策は論じられないのでは？ Developer Teamにメールが届くのを待つべきかと --
- こんにちは。推測まじりの議論は止めましょう。メールなど届いてはいません。 -- henoheno
recent.inc.php1.16ではGSは「#recent(): You called me too much」と表示されますね。Orangeboxは左右のメニューバーと本文の3箇所に表示されます。 -- hirokasa - ↑は間違い。recent.inc.php1.16ではGSは右に、Orangeboxは左に「#recent(): You called me too much」と表示されます。本文には両者ともrecentが表示されます。 -- hirokasa
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
