👏
そろそろ理解しよう"セッション"と"クッキー"
結構聞かれることが多くなってきたので、自分の復習がてらにまとめる
参考にさせていただいた動画
前提
HTTP通信はステートレス（状態を持たない）なので、前のリクエストと今のリクエストが同じユーザーで行ってるかどうかの認識がサーバ側で判断できない
セッション
セッションとは大抵、前のリクエストと今のリクエストを同一のユーザーとして認識することという意味
前のリクエストと今のリクエストを、同一のユーザーとして認識してくれなくなった
👉セッション切れを起こした
クッキー
- セッションにおけるクッキーは、ブラウザとサーバの通行手形のようなもの
- クッキーには同一ユーザーだとわかる最低限のデータ、（ユーザーIDなど）だけ持たせる
セッションのためにクッキーを使う
👇言い換えると...
サーバが同一ユーザーのリクエストであることを、認識するため（目的）にクッキーを使う
クッキー生成手順
- ブラウザのリクエスト時、サーバがクッキーを作ってブラウザに渡す（ブラウザがクッキーを持ってない場合発火）
- 次回アクセス時にブラウザから、サーバにクッキーを渡して同一ユーザーだと認識してもらう
クッキーの特徴
- クッキーは4KBまでしか保存できないので、大きなデータは保存できず、データにはメタ情報や有効期限、有効ドメインなどが書かれている
- クッキーはブラウザ（クライアント）で保存してるため、ユーザー側で書き換えが可能
クッキーの確認
デベロッパーツールの、アプリケーションタブ内で、今ブラウザにあるクッキーが見れる
セッションID
サーバがクッキーを生成してブラウザに渡す際、大きく分けて２つのやり方がある
1. セッションIDを使わずに、クッキーにデータを入れる
👉署名付きの暗号化をするのが一般的
例：暗号化したユーザーIDをクッキーに入れ、ブラウザに渡す
2. クッキーにセッションIDを入れる
👉サーバ側でセッションIDというIDを発行、それをクッキーに埋め込む
👉基本的に各webサービスはこっちを使ってる
例：ユーザーIDはRedisなどのデータストアに入れておき、ユーザーIDと紐づくセッションIDを生成し、セッションIDが書かれたクッキーを渡す
結論
セッションは目的でクッキーは手段
TIPS
セッションハイジャック・・・悪意のあるユーザーにクッキーを盗まれ、そのユーザーが盗まれた人として、サーバに認識されること
Redis・・・nosql、複雑なことはできないが、速度が早いといった利点がある
セッションを保存するデータベースとして、複雑に保存しておくMySQLなどのデータベースと分けて設置される
この時データはMySQLとRedisに重複して保存されることになる
Discussion