Rails tutorial 第８章
基本的なログイン構造
- ブラウザがログインしている状態を保持し、ユーザーによってブラウザが閉じられたら状態を破棄するといった仕組み (認証システム (Authentification System)
- この認証システムの基盤が出来上がったら、ログイン済みのユーザー (current user) だけがアクセスできるページや、扱える機能などを制御していきます
なお、このような制限や制御の仕組みを認可モデル (Authorization Model) と呼ぶ。
この第8章と第9章を通して、1: ブラウザを閉じるとログインを破棄する (Session)、 2: ユーザーのログイン情報を自動で保存する (Cookie)、3: ユーザーがチェックボックスをオンにした場合のみログインを保存する (Remember me) 、という３つの一般的なログイン機構を実装することになります
1.セッション
- HTTP == statelessなプロトコル。過去を捨てた旅から旅の流れ者的なプロトコル（強者）
- よって別のページに移動したときに、ユーザーのIDを保持しておく手段が全くない
- Webアプリケーションでは、セッション (Session) と呼ばれる半永続的な接続をコンピュータ間 (ユーザーのパソコンのWebブラウザとRailsサーバーなど) に別途設定
- Railsでセッションを実装する方法として最も一般的なのは、cookiesを使う方法です
- cookiesとは、ユーザーのブラウザに保存される小さなテキストデータです。cookiesは、あるページから別のページに移動した時にも破棄されないので、ここにユーザーIDなどの情報を保存できます
- UsersリソースではバックエンドでUserモデルを介してデータベース上の永続的データにアクセスするのに対し、Sessionリソースでは代わりにcookiesを保存場所として使う
Sessionsコントローラ
- ログインのフォームは、この節で扱うnewアクションで処理します。
- createアクションにPOSTリクエストを送信すると、実際にログインします (8.2)
destroyアクションにDELETEリクエストを送信すると、ログアウトします
Sessionリソースではフルセットはいらないので、「名前付きルーティング」だけを使います
GETリクエストやPOSTリクエストをloginルーティングで、DELETEリクエストをlogoutルーティングで扱います
rails routesコマンドを実行してみましょう。いつでも現状のルーティングを確認することができます
ログインフォーム
- セッションフォームとユーザー登録フォームの最大の違いは、セッションにはSessionモデルというものがなく、そのため@userのようなインスタンス変数に相当するものもない点です。したがって、新しいセッションフォームを作成するときには、form_forヘルパーに追加の情報を独自に渡さなければなりません。
ユーザーの検索と認証
- ログインでセッションを作成する場合に最初に行うのは、入力が無効な場合の処理