プロになるためのweb技術を読んで 3

Cookieとsessionについて

こんにちは！

Mosバーガーの美味しいシェイクを食べながらカタカタしている福地です。

今日書いていくのは、Webアプリケーションの重要でかつ基本的な仕組みであるCookieとsessionについて

・HTTPの問題点

・Cookieとは

・sessionについて

という流れで書いていきます。

HTTPの問題点

HTMLを閲覧できる仕組みであるHTTPですが、何かと問題点があります。その一つとして「状態の維持」です。

これだけでわからないので、例としてアマゾンを考えて見ましょう。

アマゾンでの買い物の大まかな流れとして

① IDとパスワードを入れてログイン

②好きな商品を探してカートに入れる

③商品を注文・購入

④購入した商品を確認

⑤ログアウト　　　になると思います。

ただし、ログインの状態を保ってないと③はできないと思います。

ここがポイントです！！

HTTPが行うリクエスト処理はそれぞれ独立しており、ログイン後にしか閲覧できないものもURLさえ知っておけばログインしなくて閲覧できるようになります。ログインページとログイン後のページが独立しているのです。これは大変な問題ですよね。

ここで、それを解決するCookieが出てきます。

Cookieとは

Cookieは一言でいうと、甘くて美味しい子供達が喜ぶ食べ物です！

終わり。

...........とはいきません。

 現実世界で喜ばれるCookieですが、webの世界では通信上、重要な役割を果たしています。

その役割として 「ログイン状態の受け渡し」があります。

アマゾンの例でいくと、

 ログインページでIDとパスワードを入力したリクエストした後に、webサーバから商品一覧ページのレスポンスのついでに

IDとパスワードの情報が入ったCookieを返されます。

クライアント側からまた次のページのリクエストをする際にCookieを格納して送り返すことで、ログイン状態を保ちながら買い物ができます。そしてログアウトするとその Cookieが削除されます。

こうすることで、いきなり商品購入ページのURLを入力したとしてもログインをしていないと、Cookieが発行されていないためページの閲覧ができなくなります。

いやー便利ですね！

Sessionについて

さてこんな便利なCookieですが、弱点があり、それはログイン時に入力したIDとパスワードの情報がそのままCookieに入るということです。

これは何が問題かというと、Cookieを利用した情報のやり取りはHTTPのリクエスト・レスポンスへッダを利用して行われていますが、

第三者がちょっとしたツールを使ったらそれをのぞけてしまうのです。要はIDとパスワードが見れてしまいます。

そこで出てくるのがsessionです。

sessionのイメージとして銀行での手続きを想像して欲しいのですが、銀行で手続きをする際には、窓口に行き、受付をして受付番号をもらうと思うのですが、その番号自体では個人を特定することは不可能ですよね？？

sessionはそれと同じ考えです！

クライアント側がログインした後、webサーバ上ではクライアントのログインIDとパスワードを保管してそれを入れる代わりにsession IDと呼ばれる意味のない番号をCookieに入れます。

これで他の人に情報のやり取りを見られたとしても意味ない番号ですから分からないですよね。

先ほどの銀行の手続きを

手続きをしたい人＝クライアント、銀行 = webサーバ、受付番号 = session IDにするとわかりやすいですね！

こんな流れのWebアプリケーション上での仕組みがあります。