8.1 セッション

導入

ログインの基本的な仕組み

ログイン機構は、大きく分けると2つの仕組みから成り立つ。

認証システム (Authentification System)

通信の相手が誰（何）であるかを確認すること
認可モデル (Authorization Model)

とある特定の条件に対して、リソースアクセスの権限を与えること

上記2つが事実として、混同されがちな理由

「とある特定の条件」というのが「相手が特定の誰かであることが認証されている」という条件であることが多い。

わかりやすい例

Oauthの認証と認可

OauthとはTwitterのアカウントで外部サービスにログインしてそのサービスを利用するときなどに使われるやつ

TwitterでTogetterにログインする際、認証はTwitterですでにしてあるのでTogetterで再認証する必要はなく、単にTwitterでの権限をTogetterに委譲しているという意味合いがある。

dev.classmethod.jp

セッションとは

PC同士など、ノード間での接続情報の保持を手助けしてくれるもの。
主にはブラウザ（クライアント）とサーバを想定している。

セッションを実現するには以下の3つの方法がある。

sessionメソッド（サーバ側の技術）【永続性低】→8章
cookies（ブラウザ側の技術）【永続性中】→9章
Remember me（サーバ側の技術）【永続性？】→9章

ちなみにsessionはuserリソースと違ってActiveRecordを上位クラスに持っていないので（そういう実装をしている）、userリソースで使えることが使えないみたいなことが書いてある。
詳細は8.1.4でやるからとりあえずそんな感じなのね〜って感じで覚えておけばいい。

8.1.1 Sessionsコントローラ

ここではセッションを実装するための準備をしている。
主にcontrollerとroutesを設定している。
なので説明は省略。

8.1.2 ログインフォーム

ここではviewを設定している。

  <input class="form-control" id="session_email"
         name="session[email]" type="text" />

この辺の意味は7章に記載されてる。
paramsハッシュを思い出してみるといい。

session:
  email: 'user@example.com'
  password: 'foobar'
commit: Log in
action: create
controller: sessions

8.1.3 ユーザーの検索と認証

ここではcreateメソッドを作成している。
前項のforms要素を利用して、ユーザの入力データを取得して認証を行うまでを実装している。

8.1.4 フラッシュメッセージを表示する

flashは画面描画時に実行される（=リクエストが発生したとき）のでrenderメソッドで擬似的に描画するような場合は適用されず、ずっとエラーメッセージなどが残ってしまうことがある。
ちなみに7.29ではrenderじゃなくて、redirect_toを使ってるのでリクエストが走ってる。
そんなときはflash.newを使えばOK。
flash.newは同一リクエストで1回だけメッセージを表示させてくれる。

8.1.5 フラッシュのテスト

ここではログインが失敗する場合のテストを書いている。
次回8.2でログインが成功するテストを書く。

たくろぐ！

世界一のチラ裏

目次

導入