いづいづブログ

アジャイルコーチになりたい札幌在住SEです。アジャイル札幌スタッフ&ScrumFestSapporo実行委員。Like:パクチー/激辛/牡蠣/猫/初期仏教

Cookie

HTTPと関連が深いCookieについて学習した。

Cookieとは

Cookieの正式名称は「HTTP Cookie」である。 HTTPというのはステートレスなプロトコルであるため状態を管理することができない*1。これはHTTPが「単にファイル転送を行うために開発されたため、同じURLへのアクセスならその状況によらず同一の資源を提供する」という考えに基づくものである。

一方で、World Wide Webが普及につれ状況によって異なる内容のページを提供したいというニーズが生まれてきた(例えば「ショッピングサイトにログインしてカートに商品を登録していく」のような使われ方)。 しかしHTTPだけでは状態を管理することができないため、それを実現する仕組みとして1994年にネットスケープコミュニケーションズ社によって提案・実装されたのがHTTP Cookieである(以下全て「Cookie」と記述)。

CookieはHTTP/1.0以降から使用することができる。*2

Cookieによる状態管理

Cookieでは次のようにサーバとクライアント間の状態を管理し、サーバとクライアント間の通信において1回目と2回目で処理が異なる。

1回目

  1. ブラウザ(クライアント)がWebサーバーにリクエストを送信すると、Webサーバーはブラウザに対してレスポンスを返す。 この時、Webサーバーはレスポンスヘッダーに「Set-Cookie:」から始まる情報を付加して返却する。「Set-Cookie:」は「Cookieを保存してください」というサーバーからの指示である。

  2. ブラウザはサーバーからの指示に従い、送られてきたCookieの情報を指定された期間だけパソコンに保存する。この時、ブラウザ側は送られてきたCookieの情報の中身を理解する必要はなく、ただの文字の羅列としてしか認識しなくてよい。

2回目以降

  1. ブラウザ側では、同じWebサーバーに対してリクエストを送信するのが2回め以降の場合、保存しておいたCookieの情報をリクエストヘッダーに自動的に付加して送信する。 ブラウザ側は、Cookieが保存されていれば常に「このようなCookieがあります」とサーバーにリクエストを送る仕組みになっている。この時もブラウザ側はただの文字の羅列としてしか認識していなくて良い。

  2. Webサーバー側は、ブラウザから送信されたCookie情報を処理(=Cookie情報を分解して解釈し、HTMLに情報を混ぜ込んで返す)を行う。

つまり「HTML/1.0以降でCookieが使用可能になった」というのは「Cookieの情報を送受信する仕組みができた」ということであり、実際にはWebサーバーがCookie情報を解釈して適宜処理を行う必要がある。

Cookieの種類

HTTP Cookiesには Persistent Cookie(パーシステントクッキー)と呼ばれるものと Session Cookie(セッションクッキー)と呼ばれるものの2種類ある。

Session Cookie

Session Cookieはサイトの閲覧中にのみ一時的に保存され、ブラウザを閉じるとユーザーのデバイスから削除される一過性のCookie

Persistent Cookie

Persistent Cookieはユーザーのコンピューターに保存されブラウザを閉じても削除されない。 Persistent Cookieはブラウザの削除オプションを使用して削除することができる。

Cookieの注意点

Cookieの利用はアクセスした瞬間に必要な情報が表示されるという点で便利ではあるが、使い方を注意しないと第三者に情報を盗まれる危険性がある。 多くのユーザーの目に触れるような環境では、必要がなくなったタイミングでCookieの情報を削除する、自分の信頼するWebサイトにだけCookieを使用するようにするなどの注意が必要である。

セッション

セッションとは、一連の処理の始まりから終わりまでのこと。 例えばネットショッピングの場合、ログイン⇒商品をカートに入れる⇒購入のような同一利用者からの一連のアクセスを1つのセッションとして扱う。

Cookieを使ったセッション管理

上記のように同一利用者からのアクセスを関連性のある一連のアクセスとして扱いたい場合、Cookieを使ってセッション管理を行う。

具体的には、Cookieに一意の値を入れリクエストするときにこの値をCookie入れて送ってもらうことで識別する。以下に例をあげる。

  1. ブラウザはWebサイトにログインし、ユーザIDとパスワードをWebサーバに送信する。
  2. サーバはユーザIDとパスワードから「セッションID」を生成し、「Set-Cookie:」に追加してブラウザへ送信する(例:Set-Cookie: PHPSESSID=028a9x...)。この時なりすましを防ぐためセッションIDは特定しにくい値にする必要がある。
  3. 以降ブラウザがWebサーバにリクエストを送る際、セッションIDを含んだCookie情報を送信することでセッションの維持ができるようになる。

結局のところ「セッションを維持する間は、識別可能な一意の値をやりとりする」ということをCookieを使って行っているということなので、例えばCookieを使わずにリンクのURLに値を記述してリクエストしてもらったり、フォームに値を記述してリクエストしてもらうという方法をとることも可能といえば可能。

ただし、Cookieを使う方法と比べて情報が漏洩する可能性が高いため、Cookieを使ってセッション管理するのが一般的である。

*1:ブラウザがサーバに立て続けに2回リクエストを送ったとして、 サーバには、1回目のリクエストと2回目のリクエストはまったく独立したものとして扱う。

*2:HTTP/0.9ではメソッドはGETしか存在せず、それに対するレスポンスもただHTMLを返すだけという非常に単純な作りだった。HTTP/1.0では、メソッドはGETのほかにPOSTなども使用できるようになり、レスポンスもレスポンスヘッダーやレスポンスステータスを返せるようになった。Cookieの情報はレスポンスヘッダーに含まれる。