Makoto Satoh
makot****@yahoo*****
2004年 9月 3日 (金) 10:32:06 JST
佐藤です． --- Shiro Kawai <shiro****@lava*****> からのメッセージ： > セッション管理は、アプリによって要求が結構異なるので、 > アプリ毎に書いてしまった方が速いかなと思って今まで作って > いませんでした。それと、使いまわしが出来るほどちゃんと > 作るのは結構難しいので。でもうまい具合にコモンケースが > 括り出せるならモジュール化してしまっても良いでしょうね。 簡単なCGIを書いているときに，関数化してしまえば良いとは言え， Distribution付属のしっかりしたモジュールがあると安心だなと いうのが動機なんです．いつまでもそれだからスキルが向上しない のかも知れない(自爆)． > ちなみに、既存のセッション管理の仕組みでは、次のような > 問題はどんなふうにハンドリングされているのでしょうか： > > * 「Backボタン」問題：sessionオブジェクトへの操作が > 破壊的である場合、ユーザがBackボタンで操作前の画面に > 戻った時に、正しく状態が巻き戻せない 最近，PerlのCGI::Frameworkを色々調べています．このモジュールは， CGI.pm，CGI::Session，HTML::Templateをうまく使っていると思います． このCGI::Frameworkのコンストラクタに渡すオプションに， disable_back_buttonがあります． disable_back_buttonに真の値を指定すると，単にキャッシュさせないように するだけのようです． print "Content-type: $content_type\n"; if ($self->{disable_back_button}) { print "Cache-control: no-cache\n"; print "Pragma: no-cache\n"; print "Expires: Thu, 01 Dec 1994 16:00:00 GMT\n"; } さらに，CGI::Frameworkではセッションオブジェクトに，最後にクライアントに 送り返したテンプレートの名前を覚えさせています． > * 「Clone」問題：操作の途中で、ユーザがそのurlを別画面で > 開いたりして、双方で別々の操作を続けた場合、cookieだけに > よるセッション管理では、両方の操作を別のものとして追うことが > できない。 この問題は今まで意識したことないのですが，PerlのCGI::Sessionでは 解決されていないと思います．ちょっと回避方法は思いつきません． > * Expiration：永続プロセスの無いcgiの場合、たまってゆく > 永続セッションオブジェクトをどういうタイミングでexpireすべきか 例えば，PerlのCGI::Sessionのデフォルトのセッションデータの格納方法は プレーンファイルで，そのファイルを作るディレクトリをコンストラクタで 指定しますが，それらのファイルを消すロジックのことですよね？ CGI::Sessionのデストラクタからflush()というメソッドが呼ばれ， セッションオブジェクトが内部的に持っている_STATUSというフラグが DELETEDだと，remove()が呼ばれます．このremove()はセッションデータの ストレージ(ドライバ)で実装されます．デフォルトのFile.pmでは単に unlink()するだけです． この_STATUSがDELETEDになるのは，セッションオブジェクトにアクセスが あると毎回内部に持っている時刻データと指定されたexpiredが比較され， expireされるべきオブジェクトの場合は，DELETEDにセットされます．
