PHPのフレームワークsymfonyの新しいバージョンがでました!
主な変更点はFivestarさんが簡単にまとめられてます。
1.2のメンテナンス期間の終わりを根拠に1.0を使い続けるという人がいて最近悲しかったですが、これで堂々と「新規プロジェクトは1.4で」「1.2は1.3で(可能なら1.4)」とできますね。
メールライブラリとしてSwift Mailer 4が同梱されていますが、まだJISメールの問題が直ってないので、ご注意ください。
単発でsymfony1.3/1.4からメールを送りたいだけなら、日本語JISメールに対応した他のメールライブラリをlib/vendorに突っ込んで呼ぶとかでいいと思います。symfonyとSwift Mailerが用意しているいろいろな技をJISでも活用するには、もう少しお待ちください。
symfonyの導入は、新しい1.3/1.4でも日本語のマニュアルが既に用意されています。
PHPの文字エンコーディングの入力チェックを改善する方法について日本語のブログで議論があり、そのパッチを本家に提案したが、却下された、という話が盛り上がっているようです。
バグレポートされた岩本さん自身や、コメント欄やはてなブックマークでは、
みたいな意見があまりに大勢をしめているので、そのバグレポートを見てみた上で、思ったことを述べたいと思います。
岩本さんのバグレポートを訳すと、こんな感じです
要約:
------------
セキュリティ的な要件により、htmlspecialchars()はバイト列をもっと
厳密にチェックすべきです。XSSするコードが見つかりました。
http://d.hatena.ne.jp/t_komura/20091004/1254665511 [日]
原始的なパッチを書きました。
http://iwamot.com/misc/html.c.patch.20091006
使えるかどうか知りませんが(笑)
再現コード:
---------------
// 越長 UTF-8 列
echo htmlspecialchars("A\xC0\xAF&", ENT_QUOTES, 'UTF-8');
// 不正な Shift_JIS 列
echo htmlspecialchars("B\x80&", ENT_QUOTES, 'Shift_JIS');
echo htmlspecialchars("C\x81\x7f&", ENT_QUOTES, 'Shift_JIS');
// 不正な EUC-JP 列
echo htmlspecialchars("D\x80&", ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("E\xA1\xFF&", ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("F\x8E\xFF&", ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("G\x8F\xA1\xFF&", ENT_QUOTES, 'EUC-JP');
予期する結果:
----------------
何も出てこないこと
実際の結果:
--------------
A_&B_&C&D_&E__&F__&G___&
("_"は不正なバイトを意味します)
もしあなたが日本語でオープンソースのプロジェクトをやってて、他にも毎日バグレポートを受けているような状態で、こんな感じのバグレポートが来て、「問題の詳細はこのURL、アラビア語ですけど」みたいに書かれていたとして、この問題について調査を始めたり、優先してこの問題に取り掛かったりするでしょうか? 僕ならしないと思います。
ましてや、”I don’t know whether it is useful though 
” 「使えるかどうか知りませんが(笑)」ですよ? こういうのは日本的な謙譲の美徳として日本のコミュニティでは通じても(どこでも通じるかはわかりませんが)、およそ真剣に「この問題について知ってほしい、興味を持ってほしい」という態度とは受け取られないと思います。
それまで、複数のブログでいろいろな人がしっかりした問題点の検証や議論を、かなりの長文の日本語でされていて、日本語でそれらを読んでいる人にとっては問題は自明なのかもしれません。
しかし、PHPの開発は英語でコミュニケーションされてますし、彼らが英語で上のバグレポートに出てくる断片からウェブを検索したとしても、日本語での議論のようなまとまった情報は見つからないかもしれません。
日本語で議論されている皆さんの努力にはとても敬意を払っていますが、最終的な問題がPHP本体を直すことにあるのであれば、英語に持っていって相手を説得するときに尻すぼみになっているのは残念です。
僕も英語でバグレポートするのは大変ですし、岩本さんのレポートも、パッチもあるし問題の背景が共有されているなら十分だとは思いますが、何が問題で、直さないとどういう問題が起こるか、起こったとして被害の大きさはどれぐらいか、修正がこれまでの他アプリにどんな副作用を起こしうるか(あるいは起こさないか)、といったことを書かないと、むしろ取り合わないのが普通じゃないかと思います。
はてなブックマークのコメントで書いたところ、岩本さんからこう追記をいただきました。
id:AKIMOTOさんに限らず、私のレポートの仕方が悪かったせいだと思われる方、ぜひ本件を引き継いでいただけないでしょうか。私の望みは htmlspecialchars の文字エンコーディング妥当性チェックが改善されることであって、どなたかが達成されるのであれば、それで万々歳です。採用されるレポートの書き方もそれで分かるでしょうし。
他人の英語について何かコメントしたら、こういう返しをされるだろうな、というのはわかっていました。
しかし、それぞれの人はそれぞれの優先順位があります。この問題が無視できる問題だ、とは僕は思いませんが、僕自身がこの先解こうとしている他の問題に比べれば、自分で引き継ぐほど差し迫った不利益を受けていませんし、また、議論されているみなさんほど、この問題について精通してもいません。英語が書けるというだけで、誰もが替われるような話ではないでしょう。少なくとも僕にはこの件の翻訳ボランティアになる動機がありません。
ただ、それが「自分に取って優先順位の高い問題で、どうしても通したい」ときにどうしてるか、は紹介できるかと思います。
ちょうど昨日、僕も一本のバグレポートを書きました。主な興味の対象のレイヤーが違うのですが、PHPのメールライブラリSwift Mailerのバージョン4に関するもので、日本独自仕様の提案に関係するものです。
具体的には、NTT Docomoなどが過去に間違って導入した、RFC違反の形式でピリオドを持つメールアドレスを受け付ける特別なモードを導入してほしい、というものです。
PHPとSwift Mailerではレイヤーも規模も、何もかも違いますが、
- 何が問題なのか
- その問題に他のアプリケーションはどう対処しているのか
– mail addressの場合、iPhoneやGmailが日本市場向けに何をしているか書きました
– 文字エンコーディングの入力チェックの場合、他の言語や処理系でどう扱っているか、というような話になるかと思います
- その変更を採用することで、既存のユーザーに影響するか
– 今回は影響するもの、影響しないものを合わせて複数の取りうる修正案を併記しました
といったことをまとめ、何が問題で、どうしてこんなばかばかしいRFC違反のメールを受け付けられることが日本の一部のユーザーにとって(ひいてはSwift Mailerの日本での普及にとって)大事か、というのを伝えようとしたつもりです。なんといっても、こんな修正日本以外のユーザーには何のメリットもないですからね。
# ちなみにこのレポート書くのに何日もかかってます。英語でブログ書いてるからといって、複雑な内容を一瞬で書けるわけではもちろんないです。
このメールの件は、いわば「悪い仕様を追認する」汚い修正なので、念入りにiPhoneなど他社の対応状況も添えましたが、PHPのエスケープで起こる問題が本当に筋のいいものであれば、これまでの日本語での議論をきっちりまとめて伝えることで、それよりは受け入れやすいのではないかと思います。
英語でバグレポート書くのも大変でしょうし、却下されれば凹みもするでしょうけれど、それを日本語に持ち帰ってきて「残念だ、残念だ」と騒いでも、それは決して相手に伝わらないですよ。
はてブコメントで「残念」と書いている人の中に、そのバグレポートを開いて見てみた人がどれぐらいいるんでしょうか。
「いつもの同じ問題」じゃないとわからせるには、わからせるだけの証拠を積み上げて見せないといけないし、バグレポートで届かないなら、(英語の)ブログを書いたりサイトを立ち上げたり、メーリングリストで問題提起したり、却下した本人にメールしたり、いろいろとあるのではと思います。
この問題で議論されているみなさんの努力、バグレポートまで書かれてチャレンジされた岩本さんの努力には(一PHPユーザーとして)たいへん感謝していますが、努力することが重要なのじゃなくて、どうやって自分(達)の意を通すかが大事ではと思います。それが「PHPのせい」「コアチームのせい」「英語のせい」「外国人のせい」で終わってしまうとしたら、僕はそれが残念です。
# あと、↑途中書いた僕自身のスタンスをよく読まずに「じゃあお前やれば」とコメントしないでくださいね。僕の次のバグレポートは、Swift Mailerでのiso-2022-jpサブジェクト行のエンコード&行分割に関するものになる予定です
[追記 2009.10.09]
徳丸浩さんが、PHPが今すぐ直らないとしても実施できる、このセキュリティホールが起こりうる条件と、その回避法についての解説をまとめられています。
[追記 2009.10.09]
moriyoshiさんが最初のバグレポートをcomitしてくださいました。ありがとうございます。
将来のマイナーアップデートリリースでこの問題は解消されるでしょう。実際に今このセキュリティホールが有効になる条件下のアプリケーションを運用されている方は、個別にパッチをあてたPHPをビルドして差し替えるか、上の徳丸さんの対策を行なう必要はあります。
PHPカンファレンス当日でいろいろと連絡が滞っていてすみません。
6(日)昼の「symfonyのFabienさんと東京観光」は予定通りやります。これまで参加を表明された方は、朝10:00に四谷に集まると思っていてください(途中から参加とか遅れる人のために、あとでメールで詳細は送ります) まだ人数増やせると思うので参加表明はこちらを読んでください。
6(日)の夜、こちらも四谷近辺で、Symfony Meetupをやります。懇親会です。いい機会なのでsymfony使いで集まってゴハンを食べましょう。
Symfony Meetup Tokyoは盛況のうちに終了いたしました。参加くださったみなさま、ありがとうございました!
PHPカンファレンスの開催がいよいよ明日・明後日となりました。
今回は、10周年ということで海外からも3名の講演者をお呼びしての充実したカンファレンスとなっています。(参加は両日とも満員で締め切っています)
symfonyのリーダーFabien Potencierさん、FacebookのBrian Shireさん、台湾PHPユーザー会の江 明宗さんのお三方は、なかなか東京で話せる機会もないと思いますので、ぜひ取材等いかがでしょうか? (拙いですが通訳できます)
特に、カンファレンス当日はPHPカンファレンスのメディアスポンサー各社(スポンサーありがとうございます)のみなさまに、ぜひ取材いただければと思います。
ご興味ありましたら、ぜひPHPカンファレンスでお声をかけていただくか、akimotoアットgmailかtwitter.com/akkyまで御連絡ください
symfonyユーザーの皆様
きたる5日(土)のPHPカンファレンス2009テックデイでは、symfonyのプロジェクトリーダー兼Sensio社の社長であるFabien Potencier(ファビエン・プートンシェ)さんがはるばるフランスから初来日し、symfonyプロジェクトについて講演されます。
今回が初来日、また講演の翌日6日(日曜日)がオフということで、Fabienさんと一緒に日本のsymfonyコミュニティ(ユーザー/開発者)のみなさんとめぐる東京一日観光を行ないます。
二日間のPHPカンファレンスの直後でお疲れかもしれませんが、symfonyの今後についてやプロジェクトの要望などについて直接Fabienさんと話せる貴重な機会になるかと思います(通訳は有志2,3名でお手伝いしますが、ちょっと勇気を出して直接英語で、あるいは仏語でお話してみるのもよいかと)。
ツアー名: (仮)symfonyについて語りつつ一日東京観光
日時: 2009年9月6日(日) 朝から夜まで
場所候補(検討中): 浅草寺・秋葉原・皇居・明治神宮/原宿・まだ大地に立ってればお台場ガンダム・都庁展望台・他に面白いところあれば
移動手段: 電車/徒歩メイン
参加資格: symfonyを使ってる、使いたい、これを機に○○○○○○○から切り替えてみようかな、という人。あと昼食夕食場所の手配とかもろもろ手伝ってくれる人
予定人数: 多くて10人ぐらい? そこまで居ないと思いますが、20人とか30人とかになったらたいへんかもと思いますがどうでしょう?
申し込み: 「a k i m o t o あっと gmail どっと com」へ、サブジェクトに「symfony東京観光参加希望」と入れてください。金曜夜締め切り
symfonyでsuper cacheを実現するsfSuperCachePluginの、symfony1.2での使い方について。
super cacheは、動的にページを生成するWebアプリケーションにおいて、ほとんどの場合にWebサーバの仕組みを使って静的に作成したhtml(等)を直接クライアントに返すことでサーバの応答を早くし、サーバの負荷も軽減する手法です。
よく知られているのはWordPressのSuperCacheプラグインです。これを正しく設定すれば、動的生成でありながら静的生成のパフォーマンスを持つブログを運営することができます。
これまで自作でsuper cache相当の仕組みを作ったことはあるのですが、symfonyのプラグインがあるのでこれが使えるかどうか調べてみました。
とりあえず、READMEにあるように進めてみます。
まず、プラグインはsymfony1.0にしか対応していませんので、普通にsymfonyコマンドでインストールしようとするとエラーになります。
コマンドインストールで失敗したときはいつもそうですが、パッケージを持ってきて自分で展開してみます。バージョンチェックが入ってるだけのことも多いので、これで動いてしまうプラグインも多いです。
> wget http://plugins.symfony-project.org/get/sfSuperCachePlugin/sfSuperCachePlugin-1.0.5.tgz
展開したら、sfSuperCachePlugin-1.0.5 というフォルダを、symfonyの作業フォルダ以下の plugins/sfSuperCachePlugin というフォルダにリネームしつつコピーします。
あとは、pluginsの下のプラグインを全部読むようになっていればsymfony ccするだけで自動的にロードされます。なってなければ、config/ProjectConfiguration.class.php のsetup()で、enableAllPluginsExcept()等を使って読み込まれるプラグインに指定してください。
このまま先へ進んでいくと、1.0と1.2の非互換でエラーになります。先に修正箇所を示すと、sfSuperCacheFilterの次の行
$uri = sfRouting::getInstance()->getCurrentInternalUri();
を、以下のように変更する必要があります。
$uri = sfContext::getInstance()->getRouting()->getCurrentInternalUri();
(symfonyアプリ)/web 以下に、静的ファイルの置き場を作ります。READMEにならって”cache”ディレクトリにします
> cd web
> mkdir cache
Un*xの場合はオーナーやパーミッションも調整してください
プラグインの中に入ってるphpは、フィルタファイル一個だけです。これを(frontend)/filters.yml の # insert your own filters here のところに追加します。
supercache: class: sfSuperCacheFilter param: cache_dir: cache with_host: false
ホスト名を複数持たないならwith_hostはfalseでいいです。持つ場合、この後の設定も準じて変わるのでREADMEを読んでください。
web/.htaccess を書き換えます。以下の2行のところを、
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
たとえば、以下のように書き換えます。
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{DOCUMENT_ROOT}/symfony_apps/sandbox/web/cache/supercache/%{PATH_INFO}.php -f
RewriteRule ^(.*)$ cache/$1.php [L]
この書き換え、READMEについてきたREQUEST_URIを使ったものが動かなかったので、自分で動くものを探してこんな風にしました。サブディレクトリにアプリを置いたりしなければREADMEのままのでも動くのかも。mod_rewriteは難しくてよくわからんです。
mod_rewriteが思うように動かないときは、とにかくhttpd.confの設定でrewrite logを取り、出たログを読みましょう。
やってるのは、
web/cache/ほげほげ/ふがふが.php
というファイルがアクセスされて、もしそれがあったら、そのファイルを直に実行して表示してしまう、という処理です。
もしファイルが無かったら、mod_rewriteの処理は下方のルールに落ちて行って、いつものフロントエンドコントローラ(web/index.php)を呼ぶようになっています。
これで、staticファイルが出来てればそのまま表示、出来てなければsymfonyを普通に実行(し、filters.ymlで挟んだフィルタがstaticファイルを生成)、というsuper cacheが完成となります。
フィルタファイル sfSuperCacheFilter.class.php の中を読むとわかるのですが、super cacheが発動するには、いろいろな設定がされている必要があります。そうしないと、super cacheを動かしてたつもりが普通のキャッシュされたファイルを見てたりすることにもなります。
キャッシュを使うことになってるページで、ページ全体をキャッシュして問題無く、GET/POSTパラメータも渡ってこない(パラメータが違えば普通ページ内容も変わりますから)という条件。
これ全部満たして、はじめてsuper cacheフィルタが効きます。
sfSuperCacheFilter::execute()のチェック文を、デバッガ等で確認しながらsettings.ymlやcache.ymlの設定を変え、(symfony ccもして、)動く設定になってることを確かめてください。
この状態でモジュールをつくり、適当にアクセスしてください。
frontend_dev.phpとか呼んじゃダメですよ。debug offなのでprodである/ (= index.php)を呼びます。
web/cache/(アプリ名)/(モジュール名)/(アクション名).php
などとファイルが出来ていたら、まずフィルタによるstaticファイル生成は合格です。
次に、もう一度アクセスしたときにこの生成されたファイルが開いてるのか、それともsymfony標準のcacheが開いてるのかを確認します。これは、cache/frontend/prod/template/… 以下の標準のキャッシュファイルを手で消してから、ブラウザでアクセスしてみるとわかります。staticなファイルが呼ばれて開かれていれば、標準のキャッシュは作られないはずです。
とまあ、プラグインで用意されているのはここまでです。しかし、生成されたstaticなファイルは拡張子が.phpなんですね。そこでそれらのファイルをエディタで開くと、先頭にphpのコードが一行入ってます。
<?php if (time() > 1241771234) { unlink(__FILE__); header('Location: '.$_SERVER['REQUEST_URI']); exit; } ?>
これで、自身のキャッシュ寿命を計りつつ、もし寿命が来ていたら自分自身を削除してもう一度同じURLにリダイレクト、とすることで、expireの処理を行なっているようです。
と、いうことは、このsuper cache、phpを回避してないのですね。厳密には super cacheと言えないのではと思います。たとえ一行とは言え、phpインタプリタをファイル毎に起動しているのです。
このプラグインはここまでなので、PHPを完全にスルーするsuper cacheの実現には、もう一手間かける必要があります。
生成するのは.phpじゃなく.htmlにし、もちろん先頭にphpコードは入れません。.htaccessの定義も.htmlに変えます。
そうなると、キャッシュのexpire判定は自分でやらせるわけには行きません。別のトリガーでこのキャッシュファイルを消すことになります。
たとえば、cronで動かしたスクリプトで定期的にこのcache/以下を見て、ファイル生成時を見つつ古すぎるものを消す、が一案。
もう一つは、CacheManagerで明示的にキャッシュをクリアされるタイミングで、このcache/以下の該当する静的ファイルも削除することです。
super cacheで用意したcache/以下のキャッシュファイルは、先頭行のPHPでexpireを自己診断した際しか消えないので、どのみちCacheManagerでのクリアをどうするかというのは検討しないといけないですね。
変なスクリーンセイバーを愛用してると、プレゼンテーションで大恥かくかもしれませんよ。ご注意!
Embarrassing porn screensaver during a presentation. [NSFW] – The Next Web
