セッションの基本
セッションとは
セッションは、サーバーで保存されるデータ領域のようなものです。 このデータ領域は、クライアントごとに分けられます。
例えば EC サイトでカートに商品を追加することを考えてみます。
A さんが商品をカートに追加したとき、サーバーは A さん用のデータ領域を用意し、そこに商品の情報を登録します。 さらに商品をカートに追加した場合は、先程用意した A さん用のデータ領域に商品の情報を登録します。
A さんがアクセスできるのは、もちろん A さん用のデータ領域だけです。 B さんなど他の人がカートに入れた内容を参照することはできません。
このように、セッションはクライアントごとに区切られたサーバーのデータ保存領域です。 ではもう少し詳しくセッションについて説明していきます。
有効期限
セッションには有効期限があります。 当然ながらすべてのクライアントの情報をずっと保持すれば、日々サーバーのリソースが枯渇していくことになります。 そのためセッションには適切な有効期限を設定する必要があります。
この有効期限は、最後にセッションにアクセスしてから何分後に削除するといったものになります。 アクセス数とサーバーのリソースを考慮して、どのくらいの時間を設定すればいいかを考えます。 私見ですが、だいたい 30 分前後で設定されることが多いです。
有効期限が切れた場合は、クライアントは最初から操作をやり直すことになります。 そのため有効期限が短過ぎると、少し席を外しただけでもう一度やり直さないといけない、なんてことが起こります。 ユーザビリティの観点からも。どのくらいの時間を設定するかを考えることは重要です。
有効期限が切れることを、「セッションタイムアウト」や「セッション切れ」といったりします。 おそらく一度は目にしたことがあるのではないかと思います。
セッション ID
セッション ID は、整理券のようなもので、クライアントがどのセッションを利用しているかを識別するためのものです。
当然セッション ID は、一意に識別できる値でなければいけません。 大抵の場合は、言語やフレームワークによって管理されるため、発番に関してはあまり意識しなくてよいと思います。
先程の EC サイトの例でいうと、A さん用のデータ領域を用意した際、「あなたのデータは0001で預かっています」と番号（セッション ID）を発番して A さんに渡します。
A さんは0001という番号をサーバーに提示することで、自身のデータにアクセスできるといったイメージです。
サーバーの観点からすると、「0001という番号は A さんである」としているわけです。
つまり B さんが0001を提示しても、サーバーは A さんであると誤認してしまいます。
このようにセッション ID が盗まれたり、流出してしまうと、なりすましや乗っ取りといったことが起こります。 いわゆるセッションハイジャックというものです。 セッションハイジャックの方法はいくつかありますが、ここでは言及しません。
Cookie との関連性
セッション ID で説明したように、クライアントはサーバーから自身のセッション ID を受け取り、次回以降のサーバーアクセスの際にそれを送信する必要があります。 このやりとりを行うために Cookie を使用します。
Cookie についてはこちらの記事を参考にしてください。
サーバーはセッションを確保した際、以下のようにセッション ID を Cookie に設定します。 設定名に決まりはありません。
Set-Cookie: SESSIONID=0001;HttpOnly;Secureセッション ID は先述したように漏洩すると危険です。
その対策のため、HttpOnlyとSecure属性は必ず設定してください。
あとはクライアント（ブラウザ）が自動で保存し、リクエスト時に自動で送信してくれます。
Cookie: SESSIONID=0001Cookie を削除すると、クライアントはセッション ID の情報を失うため、セッションへのアクセスができなくなります。 この場合は、セッションを新規に確保してもらう必要があります。
Cookie の削除 = セッションの削除と誤認されがちですが、Cookie の削除はあくまで鍵を捨てただけです。 実体であるセッションは、有効期限までは残り続けます。