今感じていること

こう言うことなのかな。

先日の「きっとこれで」の続きで、色々調べてみました。

#	種別	設定方法	確認方法	デフォルト
1	ログイン有効期間	Auth::setExpire	クッキーの有効期限くらいかと。	0、ですが、セッションクッキー。ではなく、破棄されない。Auth.phpに書いてありました。
2	アイドル期間	Auth::setIdle	Auth::sessionValidThru	設定されていない。この場合、アイドルでログアウトはされない。これもAuth.phpに書いてありました。

setExpireに関しては、こんな感じ。

If this variable is set to 0, auth never expires

setIdleに関しては、こんな感じ。

If this variable is set to 0, idletime is never checked.

じゃ、上の二つのメソッド呼ばなければ、永遠なのか？と考えると、そうではないと。

結局の所、PEAR::Authは後ろで、PHPのセッション管理関数呼び出している訳で。当然、php.iniの設定とも関わってきます。

で、前回は、

で、さらには、php.iniのsession.cookie_lifetimeがログイン有効期間の値より大きく設定されていないといけないと。

って、意気揚々と書いて、あえなく玉砕。

で、さらに調べてみたら、ガーベージコレクション(GC)とも関連があると。

それに関係する定義については、こちらに。
第3回：PHP応用

session.gc_maxlifetime
デフォルトでは、ファイルを用いてセッション情報を保管していきます。そのファイルの存続期間です。GC が行われる際、この値を参照し、それ以前からアクセスの無いファイルを削除していく処理がおこなわれるのだとおもわれます。

つまりは、PHPのセッションは、クライアントサイドのCookieとサーバサイドのセッション情報との突き合わせが一致した時に、同一セッションだと見なす訳で。前者の有効期間はsession.cookie_lifetimeで規定されるんですけど。それとは別に後者に関しては、ガーベージコレクションの挙動に左右されると。

つまり、どんなにsession.cookie_lifetimeを大きくしても、session.gc_maxlifetimeがそのままだったら、デフォルトの1440秒(24分)で、サーバー側のガーベージコレクタ（ゴミ収集車）がsession.gc_probability / session.gc_divisorの確率で起動して、24分過ぎたセッション情報は削除されてしまうと。

なので、session.gc_maxlifetimeとsession.cookie_lifetimeを同じにしてみました。が、これを調べている途中で、しっかりと調べられている方を発見しました。

[PHP]PHPのセッション管理に使う箱選び 1

PHPには元々セッション管理の機能が用意されているので、一般的な環境であれば組み込みの関数を呼ぶだけでセッション変数を介して値の保存と取得ができるようになる。
この機能は、内部的にはセッション変数の内容をシリアライズした文字列をファイルに保存し、次のリクエスト時にはファイルの内容をアンシリアライズし変数に展開する方法で実現されている。ファイルはsession.save_pathで設定されたディレクトリ*1下にセッションIDを元にした名前で作られる。
また、セッションが開始される時、session.gc_probability / session.gc_divisorの確率でGCが起動しsession.gc_maxlifetime秒前から更新されていないセッションのファイルが削除され、古いセッションは無効になる。
以上は初期設定でPHPのセッション管理機能を使った場合の動作なのだけど、この方式にはいくつか問題がある。

今度は、性能面での問題が出てきそうですね。って、そもそも、これで行けるのか？と言う話もあり。明日まで様子見てみます。って、今日ですね。。すでに。

1/24追記
うーん、環境によって上手く行ったり行かなかったり。。もう少し確認してみます。 FC2 Blog Ranking