yamada
yamad****@tir*****
2004年 9月 3日 (金) 10:17:22 JST
山田です。 > ちなみに、既存のセッション管理の仕組みでは、次のような > 問題はどんなふうにハンドリングされているのでしょうか： > > * 「Backボタン」問題：sessionオブジェクトへの操作が > 破壊的である場合、ユーザがBackボタンで操作前の画面に > 戻った時に、正しく状態が巻き戻せない > * 「Clone」問題：操作の途中で、ユーザがそのurlを別画面で > 開いたりして、双方で別々の操作を続けた場合、cookieだけに > よるセッション管理では、両方の操作を別のものとして追うことが > できない。 これは、Kahuaのセッションや、 えんどうさん紹介のtransaction tokenのように、 ブラウザからアクセスしたステート毎の状態を保持するような セッションの実装の仕方を行わないと、回避できないと思いますので、 自分は、 - セッションは一時的な値を保存する用途には使わず、ユーザid等の 恒久的な値のみを保存し、ユーザの特定等にのみ使用する という考えで使っていました。 （で、自分の作っていたものも、そういう「簡単な」セッションです） （ただ、この場合でもログイン/ログアウト等の動作で状態が遷移してしまうので、 ログイン中にページを二枚開いて片方でログアウトすると、 上記の問題は発生してしまいますが…‥） > * Expiration：永続プロセスの無いcgiの場合、たまってゆく > 永続セッションオブジェクトをどういうタイミングでexpireすべきか 自分は、cronで定期的に、古いセッションを削除するスクリプトを 動かすようにしていました。 cgiのみで行うなら、一定回数実行毎？に、別プロセスとして 古いセッション削除部分を起動またはforkするようにするのが いいような気がします。 （STDIN, STDOUT等を元プロセスと切り離しておく必要があったりとか、 ちょっと面倒な事があるような気もしますけど） （あと、古セッション削除スクリプトを起動するかどうかの判定も、 毎回起動する普通のCGIで真面目にやるのは面倒そうです。 適当でいいなら乱数とかでいいのかな） （ただ、この部分をモジュールとしてどう提供するのが良いのかは、 ちょっと思い付きません…‥） あまり参考にならなさそうですが、とりあえず、 「簡単な」セッションと、 「ステート毎の状態を保持できる」セッションは別物として、 両方あってもいい気はします。
