セッションとは
セッションとは、サーバー側に用意される、クライアントごとのデータ保存領域のことです。このデータはクライアントごとに区切られており、それぞれ独立しています。
たとえば、EC サイトで商品をカートに追加する場面を考えてみましょう。
A さんが商品をカートに追加すると、サーバーは A さん専用のデータ領域を作成し、そこに商品の情報を保存します。さらに商品を追加するたびに、その領域にデータが蓄積されていきます。
もちろん、A さんがアクセスできるのは A さん用のデータ領域のみです。他のユーザー（たとえば B さん）のカートの内容を参照することはできません。
このように、セッションとはクライアントごとに分離されたサーバー側のデータ保存領域であり、ユーザー単位の一時的な状態管理に利用されます。
有効期限
セッションには有効期限が設けられています。すべてのクライアント情報を永続的に保持してしまうと、サーバーのリソースが次第に枯渇してしまうためです。そのため、適切な期限を設定し、一定時間が経過したセッションは自動的に削除されるようになっています。
多くの場合、この期限は「最後にアクセスしてから何分後に破棄する」といった形で定義されます。アクセス頻度やサーバーのリソース状況に応じて調整されますが、一般的には 30 分程度に設定されることが多い印象です。
有効期限が切れると、ユーザーはセッションの状態を失い、最初から操作をやり直す必要があります。そのため、短すぎる設定にすると、少し離席しただけで再ログインが必要になるといった不便が生じます。ユーザビリティの観点からも、有効期限の設定は慎重に行うべきです。
なお、有効期限が切れることを「セッションタイムアウト」または「セッション切れ」と呼びます。一度は目にしたことがあるのではないでしょうか。
セッション ID
セッション ID とは、クライアントがどのセッションを利用しているかを識別するための一意な値です。整理券のような役割を持ち、ユーザーとサーバー間のセッション対応付けに使われます。
通常、セッション ID は使用しているプログラミング言語やフレームワークによって自動的に発行・管理されるため、開発者が直接扱うことはあまりありません。
EC サイトの例で言えば、A さん用のセッションが作成される際、「このデータは ID 0001 に対応します」として、A さんに 0001 を渡します。以後、A さんはサーバーに 0001 を提示することで、自分のセッションデータにアクセスできる、という仕組みです。
サーバーは「セッション ID 0001 は A さんのもの」として処理します。したがって、仮に B さんが 0001 を提示してしまうと、サーバーは誤って A さんのセッションにアクセスさせてしまう可能性があります。
このように、セッション ID が盗まれたり漏洩したりすると、他人のセッションになりすます「セッションハイジャック」が発生します。ハイジャックの手法にはさまざまなものがありますが、ここでは詳述しません。
Cookie との関連性
クライアントは、サーバーから渡されたセッション ID を保持し、以降のアクセス時にその情報を送信する必要があります。このセッション ID の保持・送信に Cookie が利用されます。
Cookie の詳細については こちらの記事 をご参照ください。
サーバーはセッションを作成すると、以下のようにセッション ID を含む Cookie をクライアントに送信します。Cookie の名称に明確な決まりはありません。
|
|
セッション ID は漏洩すると大きなリスクとなるため、HttpOnly および Secure 属性の設定は必須です。これにより、JavaScript によるアクセスや平文通信での送信を防ぎます。
一度保存された Cookie は、ブラウザが自動で管理し、リクエスト時にサーバーへ送信されます。
|
|
なお、Cookie を削除するとクライアントはセッション ID を失うため、サーバー側のセッションにアクセスできなくなります。その場合、新たなセッションを作成する必要があります。
Cookie を削除することは、セッション自体を削除することと同義ではありません。Cookie の削除は「鍵を捨てた」状態であり、実体であるセッションは有効期限内であればサーバーに残り続けます。