今回はWEBサービス系アプリ開発で欠かせない、"セッションとクッキー"について記載いたします。
インターネットを利用されている方々の多くは何かしらのサイトで"ログイン"または"ログアウト"の経験があるかと思います。有名なサイトとしてYahoo JapanやGoogle、その他楽天、Amazon等のショッピングサイトの利用経験ある方も多いかと思います。
その際、一度、ログインすると、ログインしたブラウザを開きなおしても、ログイン状態が続いているという状況を不思議に感じたことはないでしょうか。
この仕組みに大きく関わっているのが、今回、お話しする"セッションとクッキー"になります。
早速、仕組みについてご紹介しましょう。
最初にITとは関係がない実生活における似た事例の後、IT業界での事例としてインターネットショッピングサイトの例をご紹介いたします。
①実生活における事例
セッションとクッキーと同じようなしくみの恩恵を私たちは日常生活で受けています。代表的なものは銀行窓口です。
銀行に口座開設の用事があるとしましょう。ＸＸ銀行に行きます。大変、混雑している状況を想定します。
- 【STEP1】自動発券機を操作します。
- 【STEP2】自動発券機で受け付け番号（クライアントのセッションＩＤ）が記載された小さな紙片（クッキー）をもらいます（ログイン成功です）。
- 【STEP3】受け付け番号（クライアントのセッションＩＤ）をしっかり持って、待合席でその順番を待ちます。
- 【STEP4】自分の番号が回ってきたら、受付窓口におもむき、先の受付番号（クライアントのセッションＩＤ）を再度、わたします。
- 【STEP5】受付窓口の担当者は受付番号（クライアントのセッションＩＤ）があっているかチェックします。
電光掲示板に表示された番号（サーバー側のセッションＩＤ）と一致すれば、口座開設手続きの説明を受けた後、再度、待合席で待機します。口座開設が完了し、番号（サーバー側のセッションＩＤ）が呼ばれたら、再度、受付窓口に行き、担当者は受付番号（クライアントのセッションＩＤ）があっているかチェックします。一致すれば、「先程、口座開設手続きを済ませて、新しい通帳引き渡しが必要な方だな」と判断し、改めて口座開設手続きの説明から始めるようなばかげたことはせず、手続きの続き、通帳の引き渡しが行われます（ログイン状態の継続）。
②IT業界での事例
インターネットショッピングサイトにブラウザでアクセスし、サイト内の商品を閲覧している状況を例に記載します。
- 【STEP1】Ａさんのブラウザ（以下、クライアント）から某ショッピングサイト（以下、サーバー）に初めてアクセスすると、サーバー→クライアントの向きにログイン認証要求画面が送られます。
クライアント側ではログイン認証画面でユーザ名とパスワードを入力し、送信ボタンをクリックするとクライアント→サーバーの向きにユーザ名とパスワード情報が送られます。 - 【STEP2】サーバー側ではユーザ名とパスワードが登録済みかどうかチェックします。
この時、登録済みであればサーバー→クライアントの向きにランダムに生成した不規則な値、セッションIDを含む情報、クッキーが返されます。
同時にサーバ側ではセッションID含む情報、セッション情報を一定期間（セッション生存時間）、保持します。 - 【STEP3】クライアント側ではサーバーから受け取ったセッションIDを取っておきます。
- 【STEP4】以降、クライアントからサーバーにアクセスする度にクライアント→サーバーの向きにセッションIDを送ります。
- 【STEP5】サーバー側ではその都度、保持しているセッションID（STEP2参照）とクライアントから送られてきたセッションIDが一致するかどうかチェックします。
この時、一致すれば、サーバー側は「ログイン認証に成功したクライアントからだな」と判断し、改めてログイン認証要求（STEP1参照）はせず、サーバー側→クライアントの向きにログイン成功後の画面が送られます。
③まとめ
インターネットの世界でのログイン処理は銀行窓口の受付処理に例えることができる。
（クッキーに含まれるセッションIDと銀行の受付番号は概念的に同じということができる）。
一度、ログインに成功したら、しばらくはログイン状態が続く仕組みが少しでも理解頂けたら幸いです。
次回は、ログイン処理関連についてもう少しご紹介したいと思います。
（もし、何か興味がある課題がありましたら、コメント頂ければうれしいです）。