携帯(Shift-JIS固定ブラウザ)から書き込むと文字化けする / $_REQUESTは妥当かどうか / GET固定ブラウザの扱い†
- ページ: BugTrack
- 投稿者: みこ
- 優先順位: 普通
- 状態: 完了
- カテゴリー: 本体バグ
- 投稿日: 2004-07-21 (水) 18:12:50
- バージョン: CVS(07/19)版
もくじ
携帯(Shift-JIS固定ブラウザ)から書き込むと文字化けする†
1.4.3では機能していたのですが、CVS(07/19)版では携帯で書き込みをおこなおうとおもったら、日本語が文字化けしてしまいました。*1
- wiki/ 下のファイルの中身を見る限り Shift_JIS そのままで書き出されているようです。 -- みこ
- お知らせありがとうございます。念のため、携帯電話のベンダー名を教えて下さい。それと、表示は問題なく、書き込まれたデータに関する文字化けということでよろしいですか？ -- henoheno
- えっと、N900i、P505iS、パケ割系のjigアプリ( http://jig.jp/ )、iモード
エミュレータシミュレータ( http://www.nttdocomo.co.jp/p_s/imode/flash/tool.html )の４つです。 -- みこ
- ありがとうございます。良く読めば、wiki/の下のファイルですから、書き込まれたデータですね (^^; うーむi-modeシミュレータか・・・ -- henoheno
- ちなみにテストにつかったものです。下記はどちらもiモードシミュレータでおこないました。-- みこ
- http://cafelounge.net/test/143/index.php?keitai_test
- http://cafelounge.net/test/143/wiki/6B65697461695F74657374.txt ←euc
- http://cafelounge.net/test/cvs/index.php?keitai_test
- http://cafelounge.net/test/cvs/wiki/6B65697461695F74657374.txt ←sjis
- CVS版はどんな方法で取り寄せられているでしょうか？もしもcvsコマンドをお使いであれば、大雑把な切り分け法をご紹介させていただきますので、お手数ですがお試しいただいて構いませんか？ -- henoheno
- official:CVS の cvs による方法で取得しています。はい、構いませんよ:)＞お試し -- みこ
- ちなみに、わたしのサーバ環境は redhat linux 9 です。 -- みこ
- あ、もうご返答いただいてしまった (^^; うーん、論理的にコードを眺めるべきとも思うのですが、今ちょっと心の余裕がないみたいです。すいません XD -- henoheno
CVS HOWTO: 大雑把に問題のコミットを探す†
cvs up コマンドには -D (日時を指定する) オプションがあります。これと二分法(※勘でも良い)を組み合わせることで、少ない回数で問題のコミット時刻を探索します。
- 1. 適当にPukiWikiをチェックアウトします。
- 2. 今回の場合、1.4.3のリリース日時(04/04)から7/19までの間におかしな修正が入っていると考えられます。これが初期状態です。
- 3. (問題の範囲の)およそ中間の日時を指定してアップデートします。携帯周りは私が結構手を加えている事を考慮すると、厳密に中間にする必要はありません。時刻まで指定するならば、私が作業をしていない日中が良いと思います。
例えば初回は: $ cvs up -D "2004/06/06 03:00" -dP
- 4. アップデートしたPukiWikiでテストを行います。異常が無ければ、それ以降の修正が怪しいと考えることができます。
- 5. 3～4 を繰り返し、範囲をズバズバと狭めて行きます。
- 6. 想定の範囲に異常があるのであれば、だいたい「この日あたりが怪しい」という事が見えくると思います。
- 7. なお、CVS版を取り寄せたタイミングによっては、誰か(今回は私)が続けてコミットをしている最中の、半端な状態を取り寄せてしまう可能性がありますので、最初からうまく動かない事があります。この場合、cvs -nq up で確認するなり、CVS版を取得し直すと挙動に変化が出る(直る等)、ということになります。
- あ、時刻を指定する際には、UnixのTimezoneや日本時間を考慮しないとだめです。面倒なら入れないで構いません。<= 慌てているらしい(^^; -- henoheno
- とりあえず、 7/11 9:00～7:12 9:00 の間ということはわかりました。うちのサーバはJSTです。 -- みこ
- その差分を #versionlist でみてみると、どうやら init.php(1.88->1.89)のようです。 -- みこ
- とりあえず、最新cvsから init.php だけ 1.88 に戻して 1.89/1.90 の差分を適用すると上手く動きました。 -- みこ
- ありがとうございます。助かりました (^^; init.php の 1.89 (リビジョン1.89というのは、すなわち1.88->1.89の差分ことです) がまずいという事であれば、encoding_hints に対する修正が一番怪しいですね。なぜだろう？ -- henoheno
- みこさん、encode_hint にまつわる部分だけを1.89みたいにすると、上手く動かなくなりますか？ -- henoheno
- if (array_key_exists('encode_hint',$post))
+ if (isset($post['encode_hint']) && $post['encode_hint'] != '')
こんな感じで３箇所、「空かどうか」をチェックさせただけなのですが。
- まず、報告として動きました。 -- みこ
- これは推測なのですが、$_REQUEST (=$vars)と$_GET(=$get) $_POST(=$post) ってエンコーディングが違うとか・・・(^^; -- みこ
- $vars = array_merge($get, $post);
+ $_REQUEST = sanitize($_REQUEST);
+ $vars = & $_REQUEST;
- あ、わかった。おそらく上記の部分かとおもいます。（$_REQUESTはエンコーディング変換されてない） -- みこ
- 私も別の切り口で行き当たりました。上記の様に $post と $vars が存在しているというのに、mb_convert_variables では $post のみエンコーディング変換を行っています($vars のエンコーディングを変更していません)。r1.89 で $post と $vars の依存関係をなくした際、ここのフォローが無かったのが問題の様です。 -- henoheno
- mb_convert_variables() で $vars もケアする様に修正してみました。これで 最新のCVS版でうまく動くのではないかと思います。ただし、(下の話題で既に $vars ステの話をしています様に)このコミットは $vars を推進するためのものではなく、当座のバグを潰すためのものです。 -- henoheno
- うーん(^^; 今日現在(07/25 12:00)なおってないようです。 -- みこ
- ということでパッチです。 -- みこ
--- init.php.93 2004-07-24 17:04:23.000000000 +0900
+++ init.php 2004-07-25 12:45:02.000000000 +0900
@@ -169,9 +169,12 @@
if (isset($_GET[$key])) die_message("Sorry, already reserved: $key=");
}
-$_GET = input_filter($_GET); $get = & $_GET;
-$_POST = input_filter($_POST); $post = & $_POST;
-$_COOKIE = input_filter($_COOKIE); $cookie = & $_COOKIE;
+$_GET = input_filter($_GET); $get = & $_GET;
+$_POST = input_filter($_POST); $post = & $_POST;
+$_COOKIE = input_filter($_COOKIE); $cookie = & $_COOKIE;
+
+// GET + POST = $vars(cvs 1.93 temporary patch by miko)
+$_REQUEST = input_filter($_REQUEST); $vars = & $_REQUEST;
// Expire risk
unset($HTTP_GET_VARS, $HTTP_POST_VARS); //, 'SERVER', 'ENV', 'SESSION', ...
@@ -259,12 +262,6 @@
}
unset($matches);
-/////////////////////////////////////////////////
-// GET + POST = $vars
-
-$_REQUEST = input_filter($_REQUEST);
-$vars = & $_REQUEST;
-
// 入力チェック: cmd, plugin の文字列は英数字以外ありえない
foreach(array('cmd', 'plugin') as $var){
if (array_key_exists($var, $vars) &&
- ああそうか XD 申し訳ありませんです。別件の方で array_mergeを復活させましたので、cvs:init.phpをご確認下さい。 -- henoheno
- cvs:init.php (1.94)では確認がとれました。 -- みこ
- ありがとうございます :) そろそろ私もimodeシミュレータを入手せねばならないですね。お手数をおかけしました。 -- henoheno
$_REQUESTは妥当かどうか†
- いま、1.90に上記の修正部分を元に戻す(array_margeを使う)ようにしたら、動きました。おもうに、$_REQUEST は gpc_order もしくは variables_order の影響を受けやすいので使わないほうがいいのでは？(^^; -- みこ
- $_REQUESTについて(別件)ですが、微妙なところです。初期化の時点ではなるべく不要な処理を省き、シンプルかつ高速に動く様にしたいという前提があります。$_REQUESTが gpc_order の影響を受けるのは理解していますが、デフォルトではGETよりPOSTが有利であるため、その２つだけなら問題に思っていないのです。 -- henoheno
- うーむ、改めて $_REQUEST について確認してきましたが・・・そうですね、信頼性が劣る、と考えるべきですね。一部のバージョンでは $_FILES も、そして現在でも $_COOKIE も入ってしまいますからね。 -- henoheno
- となると、$get と $post を厳密に使う世界になるので、$vars は不要になります(不要にできます)。そうすると、array_merge()のコストも無くなります。これが初期化処理のファイナルアンサーかな？ -- henoheno
- $get, $post, $vars という冗長なインターフェースが整理できればそれでいいのですが、ちょっと残念だなぁ・・・ (^^; -- henoheno
- うーん、どうなのでしょう？(^^; ここから先はPukiWikiのポリシーになるのでなんともいえませんが(^^; プラグイン作者にあたえる影響は大きそうですね(^^; -- みこ
- ポリシー（プラグイン仕様）についてですが、おそらくPukiWiki/Plug-inの仕様で書かれているところをみると、過去のバージョンでは $get、$post でやっていたけど、 $vars に移行しようとした経緯があったのではないでしょうか。 -- みこ
- いま、CVSのヒストリをざっとみたのですが、init.php(CVS:1.1)からあるからたしかに意味のないものなのかも・・・(^^; でもさすがに $vars がなくなると自作プラグイン作者も含めて大きな変更になる可能性が高いのでさすがにブランチしないと辛いのでは？（$vars -> $get, $post に移行するころには 1.5 といってもいいくらいになってきたような気も(^^;） -- みこ
- ある意味、$vars は本当に $_REQUESTと同じ「ユーザ入力機構によりスクリプトに入力される全ての変数で、 このため、信頼することができません。」（phpマニュアル定義済みの変数より引用）ぐらいのレベルなのかもしれませんね。 -- みこ
- でも、多少冗長でも 1.3/1.4系としてならばプラグインとしての互換*2のために残しておいてもいいのでは・・・とおもいます。 -- みこ
- ありがとうございます :) うーん、今までの話と、みこさんの調査をまとめると、(1) $_REQUESTは便利だが、信頼できないとした方が良い (2) $varsは便利だし、あったお方がいいけれど、$_REQUEST を使うくらいなら自力で $vars = array_merge($get, $post) として作り出した方がまし、ということですね。 -- henoheno
- これでまとめますです。現状もフォローしつつ、利便性を確保しようとするとこれ以上うまい解決策は私にも浮かんでいません。 -- henoheno
$_GET固定ブラウザの扱い†
- 個人的に心配なのはやっぱり携帯（旧J-PHONEステーション非対応機）ですね。現在の$vars形式だと問題ないのですが、 <form method= に関係なく GET パラメータで渡してくるので・・・(^^; でも、今となってはJ-PHONEステーション非対応機はかなり旧世代*3なので非サポートとしても
いい問題ないとはおもうのですが(^^; -- みこ
- ちなみに、ステーション非対応のシミュレータです。 -- みこ
- 確かに作れない事は無いでしょうけれど、そんなデバイス(ブラウザ)があるんですか・・・ XD -- henoheno
- 私のポリシーすなわちPukiWikiのポリシーであるとするほど傲慢ではありませんよ。安全かつ安定なのが一番です。そのようなデバイスを受け入れるために、 $vars = array_merge($get, $post) を残すべきだという意見もあると思います。 -- henoheno
- しかし、そのようなGET固定のブラウザを受け入れるということは、別の面で安全および安定が脅かされると思います。 -- henoheno
- PukiWikiを、GETメソッドによる操作を何でも受け入れる状態にしてしまうと、それを利用したいたずらや攻撃(書き込み攻撃でも負荷増大でもアクセスログの増大でも何でも)の標的にしてしまうことになってしまいます。 -- henoheno
- 以前からPukiWikiは、編集の際のデータは $post (= POSTメソッド)しか見ていません。また、パスワード入力もほとんどが $post しか見ていません*4。現状のCVS版PukiWikiでは、GETメソッドによるいたずらを防止する観点から、$_GET['msg']や $_GET['pass'] を明確に禁じるルーチンを別途追加しています。つまりPukiWikiに対しては、以前から、GETメソッドによる書き込みや、管理者パスワードの入力ができない状態になっています。 -- henoheno
- このような経緯からすると、残念ながら、GET固定のブラウザはデフォルトでは限定対応とさせていただいた方が良さそうです。(文書の読み取りのみ可能、書き込みなどの操作は不可能) -- henoheno
- はい、j-phoneに関してはそれでもいいかと思います。ステーション非対応機は４年も前の機種になりますし(^^; あとはポリシーとしてですが・・・（ポリシーのコメントに続く）-- みこ
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
