_ 台風ファミリー (20:17)

うわ、なにこの暑さ。さすがは台風ファミリーが通り過ぎた後だぜ。日の当たる場所に5分くらいいるだけで、意識が飛びそうになるくらい暑い。

今日はプール日和っぽいなー。根性があったら午前中のうちに近所のプールに行ったりしたら幸せなんだけど、昨日の夜は近所で火事（小火？）があったらしく、夜3時過ぎまで大量の消防車が来て騒いでいたもんだから、あんまり寝ていないんだよなー。

寝不足＆慢性運動不足状態でプールなんて行ったらゲロ吐いちゃいそう。

_ blogmapメールニュース (13:51)

• blogmapメールニュース - http://bm.ishinao.net/bm_news/

ただいま実験中。bm_news-subscribe@ishinao.netあたりにメールを出したりすると、1日に2回ほどメールが届くようになるかもしれません。メールを止めたい場合はbm_news-unsubscribe@ishinao.netあたりに。

_ dev.ishinao.net: PEAR XML-RPCの脆弱性について (20:05)

質問があったらしいんで、一応回答を載せておきます。書籍のサンプルや配布アーカイブでは特に影響ありません。ただ、サンプルを参考にXML-RPCライブラリを使ったアプリケーションを実装している場合は、pear upgrade XML-RPCしておいた方がいいでしょう。とかいいつつ、うちではアップデートで問題が出てごまかしているわけだけど。

_ 人によってパーマリンクが異なるシステム (21:40)

すげーくだらないことを思いついたんで、書いておこう。パーマリンクが人によって違うシステムならば、ディープリンクによる言及ができなくなる。

具体的には、エントリーID + '_' + md5(エントリーID + ランダムCookie)なんてものが、その人（ブラウザ環境）向けのパーマリンクになる。ランダムCookieは初回アクセス時に長期間Cookieとして発効したランダムなID（要はRURIコードね）。

そのURLにアクセスがあったら、最初の_でsplitして取り出したエントリーIDと、Cookieから取り出したIDを使ってmd5チェックして、マッチしないと内容を表示しない。

でもふつうに、記事インデックスとかにアクセスすれば、その環境向けの正しいURLが表示され、リンクをたどると中身が表示される。ランダムCookieが維持されている間は、そのURLはその人にとっては有効なパーマリンクとして働く。

ランダムCookieの代わりに、HTTP_USER_AGENTとかREMOTE_ADDRとか使ってもそれなりにいけるけど、人ごとの重複しにくさと、同一条件を維持できる期間の長さを考えると、Cookieが一番妥当なやり方だろうな。

公開はしたいけれども、あまりリンクや言及はされたくない、といったコンテンツを管理するようなサービスで使ってみたらどうでしょう。いやがらせレベルの対策だけど、運用してみたら実用レベルではそこそこいけるかもよ。

実際問題として、パーマリンクがないコンテンツは、内容が良くても言及されにくい、という現状があるわけだし。

_ セッションの怪しい挙動が直った気がする

カスタムセッションハンドラを使うといまいち再現性がない怪しい挙動をしていた件だけど、もしかしたらこれで直ったのかな？　例外ログに残ってないからエラーは出ていないのかと思ったら、httpdのエラーログの方にエラーが残っていた*1。

Failed to initialize storage module: user (path: ) 

よく分からないけど、セッションハンドラの登録の仕方がおかしいのか？　で、PEARのHTTP_Sessionのセッションコンテナ周りを見ていたら、

session_module_name('user');

というコードがあった。session_set_save_handler()するだけじゃなくて、session_module_name()を使って明示的にカスタムハンドラを使っていることを指定しなければならないんだっけ？

上記コードを追加＋セッションID再発行周りの処理をちょっと書き換えてみたところ、俺の手元ではIEコンポーネントブラウザでもおかしな挙動を起こすことがなくなった模様。後者の方も結構重要な変更（セッションID付け替え後のセッション再スタートのタイミングを変えた）なんで、どっちの修正で直ったのか不明*2。でもエラーメッセージ自体は前者の関係っぽいよなー。

_ いろいろ追加しました

各所にRSSを仕込み、ランキングとか新着系の情報も増やし、携帯用のページも追加しました（ページ送りは4、6。トップに戻るは0）。あと表側には関係ないけど、deployスクリプトを作ってちゃんと自動でdeployされるようにしました。

_ 携帯はやっぱり面倒そうだなー

フレームワークの携帯対応の実験として、携帯用のレイアウトファイルを作り、Viewに携帯用変換フィルターをかましたところ、なぜか正しく文字コードが変換されなくてしばらくはまった。

結局、コンテンツ出力前に携帯用変換フィルターをかましてしまうと、レイアウト出力時にもう一度フィルターが走ってしまう（コンテンツ部分に2回文字コード変換がかかる）というのが原因だった。コンテンツ出力前ではなく、携帯レイアウトファイルのコードビハインドでフィルターを適用したところ、正常に動作した。

携帯対応はあまり考えたくなかったんで、何となくこうやったら動くかなー程度しか考えないできたんだけど、やっぱり実際にやり始めると面倒なことが多そうだなー。