Webアプリケーション開発の中で、特に認証周りで必須の技術であるセッションとCookieについて改めておさらいしておこうと思います。
※それぞれの技術の歴史的な背景とかからを辿る記事ではありません。
Cookie（クッキー）について
Cookieをかなりざっくり表現するとクライアント（Webブラウザ）に保存されたデータのことです。
色々な技術書、記事を調べてみるとこのように書いていました。
cookieは“Webサイトとユーザー間でやり取り・保存されるアクセス情報”のこと。
https://data.wingarc.com/what-is-cookie-23546
Cookieは、クライアントに保存された情報のことです。
https://qiita.com/7968/items/ce03feb17c8eaa6e4672
Webブラウザに保存してもらいたい情報
イラスト図解式 この一冊で全部わかるWeb技術の基本
ウェブブラウザに保存された情報
https://ja.wikipedia.org/wiki/HTTP_cookie
大体同じことを書いているので、先ほど書いた通りの理解で良いかと思います。
他の特徴についても調べたので以下にまとめます。
- CookieはサーバーからのHTTPレスポンスのSet-Cookieヘッダーを使用してWebブラウザに送られ、保存される
- 保存されたCookieはクライアントからサーバーにリクエストするたびに自動送信される
- 有効期限が設定されていないCookieは、Webブラウザが閉じられると一緒に削除される（「セッションCookie」とも言う）
- 有効期限が設定されたCookieは、期限が過ぎるまではWebブラウザを閉じても削除されない
- 「クッキー名＝値」の形（1つのクッキーは4KBまで）
- ブラウザによって保持できる数が異なる
- 最近のタブ型ブラウザでは、同じPC上でタブやウィンドウを複数表示してもCookieは共有される。
CookieはWebブラウザの識別にも使われるので、他人に盗まれてなりすましをされる可能性があります。
（あんまり発生しない事案だと思いますが、共用のPCでECサイトにログインしていて、ログアウトせずPCの利用をやめた後、別の人がPCを使ったらECサイトにログインしたままの状態になっているということもあり得なくないですもんね…想像するだけで怖い…）
したがって、セキュリティ上の観点からECサイトのような金銭が絡むサービス等では、有効期限がなくWebブラウザを閉じた時に削除されるセッションCookieを使うのが一般的です。
他にも特徴はありますが、調べるとキリがないので個人的にはひとまずこれくらいでOKかなと思います。
セッションについて
セッションをざっくり言うと一連の処理の始まりから終わりまでを表す概念です。
Cookie同様、どのような表現・説明がされている色々調べてみました。
一連の処理の始まりから終わりまでを表す概念
https://qiita.com/7968/items/ce03feb17c8eaa6e4672
WebブラウザとWebサーバーのやりとりにおいて、一連の関連性のある処理の流れ
イラスト図解式 この一冊で全部わかるWeb技術の基本
「サーバ内に情報を保存し、複数ページ間で共有する」仕組みのこと
https://kanda-it-school-kensyu.com/php-basic-contents/pb_ch11/pb_1103/
一連のインタラクティブな操作のこと
https://ja.wikipedia.org/wiki/%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3
「一連の処理の始まりから終わりま」でというのは例えば
- ログインしてからログアウトするまで
- HTTP通信の接続を確立したから遮断するまで
このように色々な意味で使われます。
（前者はアプリケーションの状態としてのセッション、後者はHTTP通信としてのセッションを表します。セッションという言葉は割と意味が広いことがわかります。）
セッションの特徴を下にまとめます。
- HTTPのセッションは「セッションID」を使って同一のセッションを管理する
- セッション情報はサーバーに保存されることが多い
- セッションIDはCookieに保存し、リクエストヘッダに格納してPOSTメソッドで送受信したり、URLに埋め込んでGETメソッドで送受信したりする。
- Cookieを利用することでセッション（一連の処理）を実現できる＝ステートレスをステートフルにできる
- セッションはWebブラウザを閉じるまで保存する
- リンクなどでページを移動しても内容を保持することができる
- セッションIDのやりとりはCookieを用いる方法が一般的だが、Cookieが使えるかどうかはブラウザによるため、GETパラメータを用いてやりとりするなど他の方法をとるケースもある(セキュリティ上は非推奨)
- モダンブラウザでは、同一PC上では、必ず同じセッションとなる（IE7以前では、新規ウィンドウを開かない限り異なるセッションとなる）
- HTTPのセッションは「セッションID」を使って同一のセッションを管理する
参考までに、セッションの保存先は上記のとおりサーバーが一般的ですが僕が普段の業務で使っているLaravelではセッションの保存先を複数の選択肢の中で変更することできます。（以下記事参照）
セッション＋Cookieでできること
セッションとCookieについて概要をまとめましたが、この2つの技術は併せて使われることがほとんどです。
では、2つを組み合わせることで何ができるかというと
ステートレスなHTTPをステートフルにする
ことができます。
もう少し噛み砕いて書くと、
- Aさんがログインしていること
- Bくんが商品Pをカートに入れていること
このようなアプリケーションの状態（セッション状態とも言う）を維持できるようになります。
この2つの技術を使ったアプリケーション状態の維持は以下のような（認証が必要な）アプリケーションで使われます。
（この世の中のサービスのほとんどで使われているのではないかと思います）
- ECサイト
- 転職サイト
- SNS
「じゃあセッションとCookieを組み合わせることでステートフルにしているのか？」はこの次に書くとして、わかっている方も多いと思いますが、ステーレスとステートフルの違いについてポピュラーなハンバーガーショップを例にして軽く触れておきます。
（見飽きた、という方は飛ばしてください）
ステートレス（HTTPの標準仕様）
客「ハンバーガーセットをお願いします。」
店員「ハンバーガーセットですね。ドリンクは何にしますか？」
客「ファンタでお願いします」
店員「ファンタですね。サイズは何にしますか？」←ここで既にハンバーガーセットではなくドリンク単品になっている
客「Mでお願いします。」
店員「M？え？何がですか？」
客「え…」
ステートレス（セッション+Cookie使用）
客「ハンバーガーセットをお願いします。」
店員「ハンバーガーセットですね。ドリンクは何にしますか？」
客「ファンタでお願いします」
店員「ハンバーガーセットのドリンクはファンタですね。サイズは何にしますか？」
客「Mでお願いします。」
店員「かしこまりました。ハンバーガーセットのドリンクはMサイズのファンタですね。」
客「はい。以上で。」
このような感じでステートレスだと1回の会話のキャッチボールで前提条件が全てリセットされるので正しく注文することができません。
（厳密には「ハンバーガーセット1つで、ドリンクはファンタで、サイズはMでお願いします。注文は以上です。」という感じで言えば正しく注文することはできます）
Cookieを使用したセッション管理の仕組み
それではCookieを使ったセッション管理（アプリケーションの状態保持）の仕組みを分かりやすいように図でまとめます。
今回は「WebアプリケーションがA君がログインしているという状態を維持する」ことを例にして進めます。
セッションファイルを作成する
まずはA君が初回ログイン（HTTPリクエスト）をします。ログインに成功するとWebアプリケーションはサーバーにセッションファイルを作成し、セッションIDとログインしたユーザー（A君）の情報をセッションファイルに記録します。（今回はユーザーIDのみ）
クラアイントにCookieを保存する
リクエストを受けたサーバーはクライアント（Webブラウザ）にHTTPレスポンスを返します。この時ににSet-Cookieレスポンスヘッダーを使って、sessionidという名前で値がセッションIDである9reifwjgkrnrqfuvoijqfiのCookieをWebブラウザに保存するように指示します。レスポンスを受け取ったクライアントは指示通りCookieを保存します。
（Cookieの名前は例です。セッションIDも適当に書いた乱数です）
サーバーでリクエストしたユーザーを判別する
WebブラウザにCookieを保存した状態で再度サーバーにリクエストするとCookieも自動的に送ります。リクエストを受け取ったサーバーはCookieからセッションIDを取り出し、セッションファイルに照合をかけ、ユーザーの判別（A君であること、ログイン済みであること）をします。
このようにしてセッションとCookieを使うことでWebアプリケーションが「ユーザーがログインしている」という状態を維持することができます。（ステートフルにできる）
最後に
セッション、Cookieは認証が必要なアプリケーションでは必須の技術なので改めておさらいすることで知識の棚卸しになったし、新たに知ることもあったのでよかったです。
セッションとCookieに限らずですが、駆け出しエンジニアの時や経験が浅い時に勉強していたことって結構忘れれるし、それをある程度仕事ができるようになってから改めて復習・おさらいすると当時とは比べ物にならないくらい理解が進むことって結構あるなと感じました。
最後の「参考記事・書籍」に載せているものはとても分かりやすかったのでよかったら読んでみてください。
コメント