はじめに
概要
本記事では、Webアプリ開発で必要となるSessionとCookieの仕組みをご紹介します。そもそもなぜそのような仕組みが必要なのか。どうやって使えばいいのか。といった疑問点に対し、できる限りやさしくお答えいたします。また、Railsを用いた実装例もご紹介致します。
自己紹介
本記事をご覧いただきましてありがとうございます。私は、株式会社Mambacomでアルバイトとして勤務しているmarimo(まりも)と申します。主にRuby on Railsを用いたWebアプリケーションの開発を行っております。
本記事は、ITの業務経験が浅い私が、日々の学びをアウトプットするという意味も込めております。記事の内容に関しては十分に調査をしておりますが、もし不適切な記述等がございましたら。コメント等でお知らせいただけると幸いです。よろしくお願い致します。
まずはHTTPを簡単に
HTTPとは
HTTP(HyperText Transfer Protocol)とは、HTMLや画像などのコンテンツをやり取りするために必要な通信手順のお約束事(プロトコル)です。このお約束事を守ることで安全で正確なやり取りを実現しています。そのなかで、ステートレスというお約束を理解することが重要になります。
ステートレスとは
ステートレスはその名の通り、State(状態)がless(無い)やり取りのことです。通常、私たちがWebサイトをブラウザで見ようとするとき、ブラウザ(クライアント)がサーバに対して「...のページをください！」などとリクエストします。それに対し、サーバが「...のページを送ります！」とレスポンスすることでWebサイトを見ることができるのです。ステートレスとは、サーバがこうしたやり取りを保持しないという意味です。つまり、クライアントが「さっき商品をカートに入れたからそれを注文するページをください！」とリクエストしても、サーバは「カートに入れた商品とは一体何を指しているのでしょうか？」と困り果ててしまう訳です。
確かに、ステートレスなやり取りを行うことで、サーバの負荷を軽減したり、プロトコル自体がシンプルになったりというメリットはありますが、通販サイトでこのような事態に遭遇するのは困りますよね。そこで登場するのが、SessionとCookieという仕組みです。
SessionとCookieについて
要するに
HTTPはステートレスなプロトコルであり、サーバとのやり取りは保持されないというお話をすでにしましたが、それでも、サーバに私(クライアント)とのやり取りを忘れてほしくないと思う時は多々あります。そこで、Session(セッション)やCookie(クッキー)という仕組みを使って、やり取りを保持してもらえるようにするのです。これは双方に共通した目的ですが、その手段に違いがあります。
1. データを保存する場所が違う
セッションのデータはサーバのデータベースなどに保存されます。クライアントがサーバにリクエストすると、サーバはクライアントに対して個別のセッションIDを生成します。（セッションIDはこの後に登場するクッキーを使って管理します。）クライアントはこのセッションIDをそれ以降のリクエストで用い、サーバはそのセッションIDに紐づくデータを保持します。このようにして、他のクライアントと混乱しないようにしています。
それに対し、クッキーはクライアントに保存されます。クライアントがサーバにリクエストすると、サーバはクッキーと呼ばれる文字情報を発行し、クライアントに保存させます。クライアントはこのクッキーをそれ以降のリクエストで用い、サーバにやり取りの履歴を把握させます。（余談ですが、キャッシュという仕組みは、クライアントがWebサイトの情報の一部を記憶することで、次回以降の読み込みを素早くさせるものであり、クッキーとは異なります。）
2. 安全性が違う
セッションはサーバに保存されるため、ユーザが改ざんしたりすることは難しいですが、クッキーはクライアントに保存されるため、中身を改ざんされたり、悪意のある攻撃によって盗まれてなりすましをされる恐れがあります。対策としては、定期的にブラウザのクッキーを削除することや、安全性の高いサイト以外ではクッキーを許可しないことなどが挙げられます。
3. 保存容量が違う
セッションはサーバで管理されるため、サーバの容量に応じて柔軟に対応できます。一方で、クッキーはクライアントで管理されるため、容量に上限（一般的に4KBまで）があります。
4. 保存期間が違う
セッションはサーバに一時的に保存されるデータであるため、ブラウザを離れると破棄されます。また、時間制限を設けて自動的に破棄することもできます。そのため、再度サーバとやり取りをする際は新たにセッションIDが発行されます。一方で、クッキーは有効期限を設けない限り永続的に保存されます。
どう使い分ければよいか
以上の違いを踏まえ、セッションとクッキーをどう使い分けるべきかご説明します。
まず、セッションは、Webアプリの機能を円滑に処理するために使用するのがよいと考えます。具体的には、会員制サイトのログイン情報や通販サイトの商品カートの情報など、機密性を求められたり一時的に利用したりする情報です。
それに対し、クッキーは、Webアプリに対する利便性を向上させるために使用するのがよいと考えます。具体的には、クライアントが閲覧した商品の情報を記録し、おすすめの商品としてユーザに提案することや、頻繁に利用するサイトのログイン情報を保存するなど、長期的に利用したり入力するのが煩わしかったりする情報です。ただし、クッキーでの管理には安全性へのリスクが存在しますので、保存情報を暗号化するなどの対応が必要となります。
Railsでの実装例
ログイン情報を管理
def create
user = user.find_by(email: params[:email])
# パスワードを照合し、ログイン認証を実行
if user && user.authenticate(params[:password])
#成功したら、セッションにユーザIDを保存
session[:user_id] = user.id
# ログイン状態を保持することを許可された場合の処理
# cookies.permanentでクッキーを20年保存し、.signedでクッキーを暗号化する
cookies.permanent.signed[:user_id] = user.id if params[:remember_me]
redirect_to user
else
flash.now[:alert] = "メールアドレスかパスワードが間違っています"
render :new
end
end
最後に
本記事を最後までお読みいただきましてありがとうございました。今後も、月1本を目安に学んだ技術等を記事としてアウトプットしていければと考えております。
参考文献
Discussion