HTTPのステートレス性に基いたログイン状態の管理について
はじめに
「一度ログインしたらログアウトするまではログイン状態のまま」
サービスを利用する側として当たり前だと思っていましたが、プログラミングの学習を行う中でルールや仕組みを知ったので
アウトプットのための記事を作成します。
ログイン機能の仕組みについて
ログイン状態の管理の前に、予備知識として簡単にログイン機能の仕組みについて触れたいと思います。
たとえば、メールアドレスとパスワードでログインできるサービスがあったとします。
ログイン画面でのユーザーの動作としては以下の流れです。
- メールアドレスを入力
- パスワードを入力
- ログインボタンをクリック
この動作に関してプログラム側では以下のような処理が行われています。
- ユーザーが入力したメールアドレスとパスワードを取得しサーバーに送信
- データベースにあらかじめ登録されているユーザーのログイン情報と一致するかを照合
- 一致した場合はログインが成功し、サーバーがセッションID(後述)を発行
これで問題なくログインはできるのですが、ひとつ問題があります。 それがHTTPのステートレス性です。
HTTPのステートレス性について
HTTPはHypertext Transfer Protocol(ハイパーテキストトランスファープロトコル)の略で、インターネット上に公開されたWebサイトやWebアプリで通信を行うためのルールのことです。
HTTPにはステートレス性というのがあり「サーバー側は状態を保持しない」という特性があります。
ログイン機能における状態とは「ユーザーがログインしている状態」のこと。
つまりユーザーがログインをしてもサーバーはログインした情報を保持しないので、ユーザーがリクエストを送る度にログインした情報が消えてしまうということです。
しかし、冒頭で述べたとおりWebアプリは「一度ログインしたらログアウトするまではログイン状態のまま」というのが一般的です。
ではこの仕組みはどのように構成されているのでしょうか。
ここで登場するのがセッションIDとCookie(クッキー)です。
セッションIDとCookieとは
セッションIDは、入館証のようなものです。
入館証は、ログインした際にサーバーが発行してくれます。
この入館証の情報はブラウザのCookieが保存していて、ユーザーが何かリクエストをする度にこの入館証を見せる必要があります。
Cookieはブラウザの機能の一部で「ブラウザで情報を保持する機能」です。
実際のWebアプリだと以下の動きをしています。
- ログインするとサーバーがセッションIDを発行する
- セッションIDをブラウザのCookieが保持する
- ユーザーが別ページへのリンクをクリック(リクエスト)したとする
- リクエストと同時にブラウザが保持しているセッションIDが送信され、ログイン状態を保持したまま別のページへ移行できる
