はじめに
ログイン機能は普遍的なアプリケーションでは基本的に実装されてる機能かと思います。現代のフレームワークである Ruby on Rails や Laravel にもログイン機能用のライブラリや機構が標準で用意されており、我々開発者はとても簡単にログイン機能を実装できるようになりました。
ただ、その導入の便利さと引き換えに内部実装を理解する機会は自ずと減っていき、いざ、複雑なことをしようとすると、全体像が把握できておらず、具体的な説明を求められても、正確に解説できる人は少ないと思います。
今回は、ログイン機能の内部構造を紐解きながら理解を深めるのが主な目的です。
ログインの全体像
セッション ID の生成
ユーザーがセッションを開始すると、サーバーはユーザを一意に識別するためにセッション ID という識別子を生成します。
このセッション ID はセッション保存領域へ保存され、以降のリクエストでは、この保存領域からセッション ID を探してきます。
セッションID がイコールセッションファイルとして生成されます。セッションデータは、セッションIDと同一名であるセッションファイルにデータが保存されていきます。
セッション保存領域は基本的にファイルとなっていますが、FW などによっては設定で、redis などのインメモリデータベースであったり、RDB などを選択することができます。
Set-Cookie ヘッダーにセッション ID をセット
ブラウザに対して Cookie の登録を指示したい場合は、レスポンスヘッダーである Set-Cookie に、名前と値をセットする必要があります。（RFC6265）
レスポンスを受け取ったブラウザは Set-Cookie ヘッダーにセットされているデータを検知し、ブラウザに Cookie として登録します。
文脈によって Cookie という言葉が仕組みを指すのか、データそのものを指すのか変わってくるので、話の流れや文脈で臨機応変に解釈を変えていく必要があります。
筆者もこの記事を書くための調査の過程で、言葉の定義があやふやで混乱しました。
ブラウザに Cookie を登録
Set-Cookie ヘッダーにデータがあるとき、ブラウザは、そのデータを読み取ります。
読み取ったデータの name と value をペアで登録します。
expire の指定を行うと指定時間を経過するまでブラウザで保持されたままとなるので、永続 Cookie となり、expire の指定を行わないと、ブラウザを閉じた時点で Cookie は破棄されてしまうので、セッション Cookie となります。
永続 Cookie の方は言葉からなんとなく意味が推測できたのですが、セッション Cookie の方は最初混乱すると思います。異なる機構であるセッションと Cookie が一単語に入ってたので、？？？ となりました。
セッションという言葉は、なんらかの開始から終了までを指すので、セッションという性質を持っている Cookie と考えると腑に落ちました。
参考