初歩的な質問 セッション管理について

質問

セッション処理をしたいと考えていますが、
分からない点が多く困っています。

したいと思っていることは、「ログイン」的な処理です。

訪問者がブラウザを閉じても、サイト設計者が設定した「期間」、
ログイン状態をキープさせておけるような仕様です。

※よくあるタイプです。
（特段、難しいことや変わったことをしようとしてはいません。）

ただ、ちょっと変わっている点は、ログインはパスワード無しで行います。
フォーム（POST）でボタンをクリックしたら、誰でもログインできるようなものです。

で、上記処理をする方法として、大きく分けて、
（１）クッキー（$_COOKIE）を使う方法と、
（２）セッション（$_SESSION）を使う方法とがあるように思っています。

（１）の方法だと、
データそのものをクライアント側に保存させるのでセキュリティ上、やや難があり、
（２）の方法だと、「キー（セッションID）」だけをやりとりするので比較的安全、
ということをよく耳にします。

ただ、パスワードを扱うわけではないので、この場合には、
（１）の方法でもアリな気がしています。

しかし、今後、パスワード形式に移行しないとも限らないので、
（２）を使った方法で話を進めたいと思います。

パスワードのやりとりがないのなら、（１）の方が断然楽でいいよ～
ということであれば、話は変わってきます。
その場合には教えて下さい。

（※質問文の中で、私は随所に変なことを言っている可能性がありますので、
適宜、ご指摘頂けると嬉しく思います。）

話を戻しまして、
ここからは、前述の（２）の方法で話を続けさせて頂きます。

セッション処理の流れについてですが、
セッションIDをクライアントに送りつけ、保存させる方法は、
session_start()をスクリプト先頭に書き、
$_SESSION['login'] = 'おまえはもう、ログインしてる…。';
と、どこかに書くことで、

この$_SESSION['login']値を保持している間、訪問者は、
サイト内のページを、ログインされた状態として閲覧できる
と、私は考えています。
何か変なことを言っていましたら、ご指摘下さい。（★ポイント１）

//-----------------------------------

次に、セッション保持期間の設定の方法についてですが、
ネット上で調べた所、
ini_set("session.gc_maxlifetime", "1440");
のように設定できると書いてありました。

このini_set()による設定が、どう作用するのか、
この点もよく分からずにいます。（★ポイント２）

session.gc_maxlifetimeの設定自体は、スクリプト終了とともに、
Master Valueに戻されるようですが（PHPマニュアルより）、
私が気になっているのは、
そのスクリプトで生成したセッションの保持期間は、どうなっているのか？
ということです。

ちょっと乱暴な書き方をしますが、
例えば、

php.ini上（つまり、Master Valueの設定値）では、
session.gc_maxlifetime:1440
というような設定 の場合に、

スクリプトAの中で、
ini_set("session.gc_maxlifetime", "～仮に24時間としておきます～");
のように書き、
そのあとに、
$_SESSION['login'] = 'おまえはもう、ログインしてる…。';
と書いた場合、
クライアントには、$_SESSION['login']のデータは24時間保持される、
ということでしょうか。

つまり、
スクリプト内に書いた、
ini_set("session.gc_maxlifetime", "～仮に24時間としておきます～");
という記述は、
そのスクリプトでセッションIDをクライアントに与える場合の「そのセッションIDの保持期間」のみ
を設定できる、という理解でよろしいでしょうか。

当たり前のことをお聞きしているかもしれませんが、
どなたか、どうか、よろしくお願い致します。

回答No.7

hogehoge78

■セッションが引かれているかどうか
これの意図するところは、会員サイトなので、IDとパスなどの認証が通っているかどうかをチェックするという意味合いです。
<?php
session_start();
if(isset($_SESSION['user_id'])){
/*
例えば認証が通ってログインしたら、セッション変数にユーザのIDを格納しておくとか。セッション変数にuser_idがセットされてなければ、認証が通ってないということで、画面が遷移しないようにする。
*/
}
?>
ここらへんの実装は、ここで掘り下げなくても、理解されていますね。

■（２）と（３）の違い
COOKIEにセッションIDが残ってて、ブラウザがソレを通知してきたタイミングで、gc_maxlifetimeに到達はしているものの、GCが発動していなかった場合、ログイン後の遷移が行われてしまう可能性がありますので、プログラム側で、明示的にチェックしてやる必要があると思われます。

■セッションファイルと、その中の値であるセッション変数の関係
セッションファイルというのは、（ファイルベースの）データベースです。
実際に明示的に記述することはあまりないかもしれませんが、
http://php.nfsi.pt/manual/ja/function.session-write-close.php
session_write_closeという関数があり、セッションファイルに$_SESSION変数で保持した値を（セッションファイルに）書き込んで閉じます。これは、session_startをしていれば、スクリプト終了後に自動的に呼ばれるものです。
SQLなデータベースであれば、INSERT文やUPDATE文で行うようなことを、自動的にやってくれてるわけです。
で、session_destroyというのは、セッションを閉じるのではなくて削除します。DELETE文でテーブルやレコードを削除するのに近いですね。

■（A)の過程は、（B)をするのであれば、必要ない処理なのか
session_destroyしても、$_SESSION変数はunsetされるわけではないですので、session_destroy関数が叩かれた後も、$_SESSION変数に値が残ってますので、
$_SESSION = array();
として、リセットしたほうが良いかと思います。

■セッションが閉じられても、クッキーの有効期限が残っている場合
サーバ側にセッションが残ってないので、クッキーの有効期限が残っていても認証がされてしまうことはないと思いますが、ブラウザから無駄な通信が行われることもありますし、それ以外の何らかの予期せぬ出来事があるかも分かりませんので、削除したほうが良いのではないでしょうか。

大体のことが分かったら、後はオープンソースのログイン認証が行われるアプリケーションなどの実装を見てみるとノウハウ的な部分は分かると思います。
ECCUBE、WordPress、XOOPS、などなど。
他にも、
http://www.ideaxidea.com/archives/2007/11/phpphpuserclass.html
こちらで紹介されているようなユーザ認証部分だけのクラスライブラリなどもあったりします。

補足

＞■セッションが引かれているかどうか

理解しました！

＞（２）

GCの、
セッションファイルの削除
に使われる確率の設定具合
によって、

有効期限を迎えているにも関わらず、
存在し続けているセッションファイルを、
チェックする必要があるわけですよね。

ここ、完璧に理解できたと思います＾＾

＞（３）

で、これは、
セッション変数の中に格納する値でもってコントロールする、
セッションの有効期限、
という感じですかね。

セッションファイルの有効期限ではなく、
セッションファイルの中の１データに、
有効期限を意味するデータを格納している、
という感じで理解しました。

恐らく、ちゃんと理解できていると思います。笑

この（３）における、「有効期限」は、

（１）（２）とは異なり、その値は、一意的ですよね。

（１）は、書き換えられる可能性がある
（２）は、GC頼み
という意味で、それぞれ、一意的とは言い難いですから。

＞セッションファイルというのは、（ファイルベースの）データベースです。

セッションファイルと、その中に書かれているデータは別物なんですよね。

セッションIDの名前にプレフィックスがくっついて、
セッションファイル名になり、

そのファイルの中のデータが、
セッション変数に格納した値であり、

そのセッションファイルとクライアントを
1対１対応で結びつける際に使う技術がクッキーで、

その対応関係を照合するのに、
$_COOKIE['セッション名']にて、セッションIDを呼び出す方法を取る、
ということなのですよね。

セッション関連の動的な構成要素は、

・セッションファイル名、
・セッションID、
・セッション名、
・セッション変数（連想配列）のインデックス値
・セッション変数（連想配列）の値

こんな感じでしょうか。
なんだか、すごく分かりにくい構造をしていたのですね。
最初から、セッションという概念はややこしいものだろうなと直感していたので、質問がかなり後回しになっていました。
（クラスより後になりました。）

おかげさまで、今、ようやく分かりつつあります。

＞session_destroyしても、$_SESSION変数はunsetされるわけではない
＞session_destroy関数が叩かれた後も、$_SESSION変数に値が残ってます
＞リセットしたほうが良いかと

了解です。
では、（A）（B）（C）、
全てセットで、基本は、行っていこうと思います。

＞サーバ側にセッションが残ってないので、クッキーの有効期限が残っていても認証がされてしまうことはないと思いますが、

えっと、
session_destroy()後、
セッションファイルは消されますよね、
ということは、セッションIDもなくなりますね、
なので、
クッキーがクライアントで生き続けていたとしても、
$_COOKIE['セッション名']で呼び出される値である、
セッションIDは、既に削除済みなわけですから、
そのクッキーは事実上、無効なものであるけれども、
クッキーそのものの存在自体はまだあるわけだから、
予測不能な振る舞いをする可能性があり、
それを断つ意味で、クッキーの有効期限も無くしてやった方が良い、というわけで、

クッキーの有効期限にマイナス値を設定し、
クッキーに消滅してもらうわけですね。

つながってきました！

＞大体のことが分かったら、後はオープンソースのログイン認証が行われるアプリケーションなどの実装を見てみるとノウハウ的な部分は分かると思います。

ですね＾＾
分かる部分が多くなってきましたので、
それを呼び水に、さらに多くのことを吸収していけそうな気がしています。

セッションファイル蓄積による、サーバ圧迫が
どの程度、処理速度に悪影響をもたらすか等の、
より発展的なことがらについては、
おいおい調べていけたらと思います。

＞ECCUBE、WordPress、XOOPS、などなど。

過去、XOOPSを使った経験があるので、
古巣に立ち返ってみます。笑

当時、プログラミングのプの字も知らなかったので、
XOOPSの中に組み込まれている数々のphpファイルを
私は全く理解することができませんでしたが、
今なら、きっと理解できるはずです！

＞ユーザ認証部分だけのクラスライブラリなども

こちらも、じっくり読ませて頂きますね＾＾

ひとまず、セッションについては９割くらい理解できたものと思います。（強気　笑）

すべて、hogehoge78さんのおかげです。
いつも、ありがとうございます。