blog.longkey1.net

Ethnaで表示したページをブラウザの戻るボタンを使って戻ると、クライアント側でキャッシュしたページが表示されて、最新の状態とは異なる場合が発生。
まあ、そうだろうなって感じの挙動なんだけど、PHPのsession_cache_limiterって関数でその辺のキャッシュ絡みを制御できる模様。

んーそうなのかー。
こっちとしては、ブラウザの戻るボタンで戻った時のことまで考えてられるかって感じなんだけど、そうも言ってられないのかね。
でもまあ、この辺の挙動はブラウザの設定もあるだろうから、微妙なとこだろうな。

んで調べたらPHPのフレームワーク『Ethna』徹底解説 - GREE Labs
にこんなことが書いてあった。

Ethnaでは，session_cache_limiterで，「private, must-revalidate」に設定されているため，ブラウザのキャッシュが通常のPHPでセッションを使った場合の動作とやや違う場面があります． Ethnaで設定されているもののほうが，ブラウザがコンテンツキャッシュを行ってくれるので便利なことが多いのですが，nocacheに指定したい場合などには次の手順で修正することによって処理を変更することができます．

次の手順ってのが、こちら。
※ちょこちょこおかしなところがあったので、微修正してあるソース。

// Hoge_Session.php

class Hoge_Session extends Ethna_Session{
    function Ethna_SessionSample($appid, $save_dir, $logger) {
        parent::Ethna_Session($appid, $save_dir, $logger);
        session_cache_limiter('nocache');
    }
}

// Hoge_Controller.php

+require_once 'Sample_Session';
...（省略）...
var $class = array(
...（省略）...
-    'session'        => 'Ethna_Session',
+    'session'        => 'Sample_Session',
     'sql'            => 'Ethna_AppSQL',
     'view'           => 'Ethna_ViewClass',
);

アプリ用のセッションクラスを用意して、それを使用するようにコントローラーに追加。
Ethnaのセッション周りは癖があるので、自前のセッションクラスを用意するってのは妥当かもしれないなあ。

これにて一件落着・・・。

こちらのサイトを参考に勉強してる。
PapuhなWEBLOG - CakePHP

で、なんとなくイメージつかめてきた、CakePHP。
今まで使ってきたEthnaと比較してちょっと思ったことをメモ。

■過渡期？1.1と1.2だと結構違う
今一番難しい時なのかしら。
開発速度が早いってのも、良いのか悪いのかね。
1.1だとドキュメントも充実しているし、本もあるんだけど今更1.1ってのもなーってことで、1.2の情報が載っているブログを地道に探していくかね。
あと、CakePHP自体のソース読むのも勉強だし。
その点Ethnaは2.3.2が発表されて結構時間立っているし、こなれてきた感はある。

■bakeとかなんか今っぽい
bakeとか凄いね。
Ethnaコマンドもここまで出来ないもんなー。
Webアプリって詰まるところフォーム周りとデータベース周りだと思うんだけど、そこらへんの土台をこれだけがーっと作ってくれると、確かに後が楽だと思う。
まあ、作りこんでないからわからないけど、DB周りはcakePHPの圧勝だろうな。
テーブルのリレーションをフレークワークでやってくれるってのは、個人的にはありがたいなーって思う。


■細かいところではEthnaの方が使いやすい
Validateとかは断然Ethnaの方が使いやすい。
フォームヘルパーもEthnaの方が利いてるなー。
cakePHPメール送信機能も標準でないみたいだし、半角全角変換とか日本語周りは当たり前だけどEthnaの方が痒いところに手が届いている感じ。
こういうところ国産ってのは強いわな。


さて、なんとなく見えてきたので、なんか作りたいもの考えてさくっと試作してみたいな。
DB周りがどんだけ楽になるか、今からドキドキ。
折角だから、いくつもテーブルが絡むようなものがやりたいなー。

何がいいだろー。

既に作ったシステムを他社が管理することになった時、Ethnaの既存のプロジェクトで開発を進めてくれたら良いんだけど、そんなこともそうそう無いだろうと思って、一番ネックになりそうなセッション周りを調べてみた。
要は、Ethnaで発行したセッション値をプロジェクト外から参照出来れば、ログインシステムは既存のシステムでいけるでしょと。

// EthnaのHogeプロジェクトで発行したhogeという値を表示する

// プロジェクトごとにセッションIDが振られる
$session_name = "HogeSESSID";
session_name($session_name);

// Ethnaのプロジェクトの中の/tmpディレクトリを参照
session_save_path("/var/www/html/ethna/hoge/tmp");
session_cache_limiter('private, must-revalidate');

if (!empty($_COOKIE[$session_name]) ||
   (ini_get("session.use_trans_sid") == 1 && !empty($_REQUEST[$session_name]))
) {
    session_start();
    echo($_SESSION['hoge']);
}

一応、Ethna_Sessionクラスのコンストラクタとrestore関数を参考に書いたら出来た。
これでOKだと思うけど、もしEthnaでまた別のプロジェクトを生成し、プロジェクト間を横断となると、セッション名とか保存ディレクトリの場所を一つに統一した方が良いと思うな。
この場合は、Ethna_Sessionクラスをオーバーライドしないと駄目だな。

ログイン機能のあるサイトを作っていて、「こんにちわ○○さん～」とか「ログイン/ログアウト」を切り替えて表示したい時に、Ethnaで作っていると、王道だと全部の画面をEthnaに取り込んで表示ってことになると思う（多分）。
だけど、それはあんまりにも面倒。

デザイナーさんに静的ページ作ってもらって、こっちで取り込み・・・ってのもあまりにも非効率的だ。
デザイナーさんもやりにくいだろうし。

htaccessでmod_rewrite使ってやるってやり方もあるけど、あれあんまりすきじゃない。
で、PHPらしくhtmlファイルに埋め込みたいなと。

で、アクセスポイントのEthnaのソースを、入れたいところにそのまま挿入する。
inc_loginってアクションで、出力したいhtmlだけを出力する。

require_once '～/hoge/app/Hoge_Controller.php'; 
Hoge_Controller::main('Hoge_Controller', 'inc_login');

セッション周り使ってないと、これでもOKなんだけど、セッション使っているとこんなエラーとかでる。

Cannot send session cache limiter

つうことで、最初と最後とob_*関数で囲んで問題回避。

いくつもインクルードしたい時でも、一応これでOKだとはおもうけど、無駄も多いかもね。
とりあえずこれにて。

こんなマニアックなこと体験しているの俺だけじゃないか？
けど、分からない人はずっと分からない気がするので、メモ！

■現象
Firefoxでプロキシと通してhttpとhttpsのURLを行ったり来たりするとセッションが切れる

IEは起きないんで、なんでだーとデバッグした。
んでわかりましたよ。3時間後に。

Ethnaでは、$_SERVER['REMOTE_ADDR']をセッションに保存してる。
そんで$_SESSION['REMOTE_ADDR']と$_SERVER['REMOTE_ADDR']を比較して、あんまり違うようだとセッション削除しちゃう。
で、出力してみたら案の定全然違った。

$_SESSION['REMOTE_ADDR']＝プロキシのIP
$_SERVER['REMOTE_ADDR']＝裸のIP

要は$_SERVER['REMOTE_ADDR']が、httpとhttps間のリダイレクト時に変更してしまっていたのが問題。

どうもこりゃFirefoxの問題臭いってことで、自宅サーバー立てたときにお世話になった確認くん(VIA the UGTOP)で確認してみても、IEとFirefoxでのIPに差は無い。
あったら怖いんだけど。

で、「Firefoxのバグなんでどうしようもないですな、こりゃ」と報告しに行こうとした矢先に見つけました。
Firefoxの管理画面見てたら、SSLは別にプロキシを設定する欄があった。
・・・はぁ。
「すべてのプロトコルで～」をチェックしたら、無事ちゃんと動いたー。

実際問題分かったは良いけど、このチェックなくすとセキュリティは落ちるわけだし、Firefoxの設定をちゃんとすれば通ったしってことで、とりあえずこれはこれで終了。
なんかお客さんからクレーム来た時の為に、覚えておけば良いかな。

分かって良かった。
びびったー。