Cookieのやりとりをもっと詳しく知る

はじめに

Cookieの機能ではブラウザに情報が保存されますが、もう少し具体的にどのような形で保存されるのかについて確かめました。PHPで作成したサーバーサイドのプログラムとChromeの開発者ツールを活用しています。ブラウザで確認できるレベルのところまで見る事ができれば、通常のWEBサービスを開発する際には十分でしょう。

今回の動画のようなポイントを自分で確認できるようになると理解度も深まりますし、作成したサービスをデバッグする際にも良い手助けとなります。

今回Chromeの開発者ツールで利用したパネル

Network

RequestHeaderの欄を確認して、Cookieの実際のテキストを見ました。「email=example%40hoge.com」のところは、 「@」が「%40」にURLエンコードされています。URLエンコードはURLで利用可能な文字列になるようにする変換です。

Application

Storage > Cookiesの欄を利用してCookieのリストを確認しました。ブラウザに保存された内容がここで確認できています。削除したりするような機能もあります。

Cookies

リクエストに含まれるCookieのやりとりを丁寧に表示してくれます。Networkでの確認よりも整理されているのでわかりやすいかもしれません。

確認できたこと

1. Cookieがサーバーと共有している文字列をほとんどそのまま保存していること
2. セッションの場合にはサーバーとセッションIDという英数文字列が保存されていること
3. セッションの情報は、サーバー側に情報を保存していること
4. セッションを活用するとブラウザの中に大事な情報を保存しなくてよくなるので、より安全であること

実際のサービスでセッションに保存する情報

大抵のセッションの仕組みでは、セッションIDとシステムのユーザーのIDを関連づけて保存します。

1. ログインを行う（emailとpasswordなどを利用）
2. 1でDBから検索したユーザーのIDをセッションに保存（セッションIDを利用してアクセスしてきたユーザーのIDが探せるようになる）
3. 以後Cookie内に格納したセッションIDを利用して、アクセスしてきたユーザーを判別する

セッションの保存の仕方について

セッションの情報をどのように保存するかは特に確定した決まりがあるわけではありません（セッションの一般的な動作の仕様はあっても、実装としてどのようにするかは自由です）。今回はMAMP上のPHPの保存の場所を確認しましたが、例えば以下のような方法があったりします。

• ファイルに保存（今回確認しました）
• MySQLやPostgreSQLのようなリレーショナルデータベースの中に保存（DBのテーブルに格納してしまう方法）
• RedisのようなKey-Valueストアに保存

実際のサービス運用ではこのような方法から選択してセッションの管理を行います。WEBサーバーの台数が増えたりする場合にはファイルに保存するとセッションの維持が難しくなります。大きめのサービスではそれ以外の方法を選ぶ事が多いでしょう。