Webに携わる人なら非エンジニアも知っていて欲しい、HTTPのCookieとSession
前回の記事の続きです。
今回はHTTPのCookie（クッキー）とSession（セッション）について書いてみます。
やっぱりこれも理解していないと様々な弊害があります。
非エンジニアだから関係無いとは言い切れません。
- CookieとSessionがわからないことによる弊害
- もしHTTPにCookieとSessionが無かったら
- Cookieとは？ Sessionとは？
- 広がるCookieの用途、3rd Party Cookie（サードパーティクッキー）
- 最後に
※.前回の記事を理解している前提で書いていきます。
CookieとSessionがわからないことによる弊害
まず、わからないことによってどんな弊害があるか、例をあげてみます。
例というか実は全て私の経験談です。恐ろしー(‘Д’)
- （昔のガラケーのサイトで多い話ですが）URLにSESSIONのIDを書くようなシステムで、SESSION ID付きのURLをメルマガなどで送信してしまう。
結果：下記サイトのセッション乗っ取りと同じ状態です。セキュリティ的な大事故です！
- Sessionに入れるべき会員番号をCookieに入れてしまい、Cookieの書き換えで個人情報が抜けてしまう。
結果：これもセキュリティ的な大事故です。
エンジニアはもちろんWebサイトのセキュリティについて勉強すべきです。 IPAの「安全なWebサイトの作り方」は理解する必要があります。
非エンジニアの方もエンジニアがせっかくセキュリティ対策を行っても、人為的な穴を空けてしまいますので、基本的なことは理解しておく必要があります。
もしHTTPにCookieとSessionが無かったら
セキュリティ的な穴が開く危険性があるのに利用するわけですから、やっぱりCookieとSessionは便利なんです。 GetとPost同様、CookieとSessionもHTTPに定義されているもので、Webサーバとブラウザ間のやりとりの一部として規定されています。
Webは基本的には情報をGetする（取得する）、Postする（送信する）ものですが、状態によって画面の表示を変えたい場合があります。
例えばAmazonような通販サイトでは
- 会員登録をすると「こんにちは〇〇さん」というような個人に合わせた表示をする。
- 会員が過去にチェックした商品を表示する。
- カートに入れた商品情報を表示する。
この時、ユーザを特定するときに使われるのがCookieであり、Sessionです。
これらの説明は「CookieとSessionのおかげで、ステートレス（状態がない）からステートフル（状態を持てる）になる」と一言で言い換えられます。
「ガラケーの時代はWebサイトをステートフルにするのが大変だったなー(‘Д’)」という言い方だと「歴戦の猛者」感を演出できます！
Cookieとは？ Sessionとは？
当たり前の話ですが、Webサーバはたくさんのユーザからのアクセスがある前提で出来ています。
そしてユーザごとに画面表示を変えたい場合どうするか？なのですが、
Webサーバにアクセスがあったブラウザに対してCookieを発行する。そのCookieがユーザに対して一意のIDであればそれはSessionのIDとも言える。
ブラウザが次回以降、そのWebサーバにアクセスする際はサーバから発行されたCookieを含めて通信する。 これによってWebサーバ側ではどのユーザからアクセスがあったかを理解することが出来る。
Webサーバ側でユーザの情報を保持する仕組としてSessionがある。例えばカートに入れた商品の情報やユーザの閲覧履歴など。CookieにSessionのIDが含まれている間はユーザを特定し続けられる。
※.システム構成にSessionの管理方法は大きくことなります。大規模なサイトではSession管理だけで1冊本が書けそうです。
そして注意点としては、
Sessionの情報はあくまでWebサーバ側の情報であってブラウザ側には存在しないものです。ブラウザはCookieの仕組みでSession IDを送信するのみです。
ブラウザがWebサーバにCookieを送信する際は別のサーバで発行されたCookieを送信することはありません。送信してしまうとセキュリティ的な大問題です。
WebサーバがCookieを発行するときに、有効期間を設けられます。Session IDを保持しているCookieに有効期限を付ければ、それはSessionの有効期間となります。
Cookieよりも大きな容量のデータを保持できるWeb Storageというものもあります。
- Session IDをCookieに保存する方法もあれば、URLで送信する方法もあります。これはCookieが使えないガラケーのサイトで良く用いられた方法です。これを用いる際はセッションが乗っ取られないように、セキュリティ的な対策を講じておく必要があります。
広がるCookieの用途、3rd Party Cookie（サードパーティクッキー）
3rd Party Cookieは既に広がって久しいですね。アドテクには必要不可欠なものです。
例えばAmazonで商品を物色して、そのあとYahooニュースでAmazonで見た商品が表示される広告も3rd Party Cookieがあるからこそです。
アドテクの話をすると長くなりそうなので、アドテク以外にも3rd Party Cookieが使われている例を挙げますね。
メディアサイトでFacebookのいいね！やTwitterのフォローが簡単に行える。 これはブラウザにFacebookやTwitterのCookieが保存されていれば、わざわざログイン作業が必要無いということですね。 いいね！したときの動作としては、ブラウザとFacebookのWebサーバ間の通信で、この通信にはメディアサイトのWebサーバは登場しません。
ユーザの行動履歴を取ってマーケティングに活用。 MA（Marketing Automation）で行われていることですが、サイトにユーザをトラッキングするためのタグを貼り、その情報をもとにマーケティング活動（広告の出稿をチューニングしたり、自動でメルマガをしたり、スコアリングして重要な顧客からタッチしたり、いろいろあります）を行います。
3rd Party Cookieはユーザが意図しないところで通信が発生するケースが多いので、セキュリティ的な問題を指摘されることがありますが、もうInternetの世界では必要不可欠になってしまっている技術とも言えます。
最後に
HTTPのGet、Postに始まり、今回はCookieとSessionを説明しました。
非エンジニア向けに簡単な文章にしたつもりですが、簡単に説明するっていうのは本当に難しいですね。 今回のはそんなに難しい技術ではないんですが、、、
そしてなぜ難しいか、理由を考えたんですが、恐らく1個の技術を説明しようとしたときに、前提が多いとか、関連する技術がまた2個、3個と出てくるからかなとも思いました。
挫折する人ってそういうところで挫折するのかなー
