8.1.1 Sessionsコントローラ

ログインとログアウトの要素を、Sessionsコントローラの特定のRESTアクションにそれぞれ対応付けることにします。ログインのフォームは、この節で扱うnewアクションで処理します。createアクションにPOSTリクエストを送信すると、実際にログインします (8.2)。destroyアクションにDELETEリクエストを送信すると、ログアウトします (8.3) (表7.1のHTTPメソッドとRESTアクションの関連付けを思い出しましょう)。

最初に、Sessionsコントローラとnewアクションを生成します。

$ rails generate controller Sessions new

newアクションを生成すると、それに対応するビューも生成されます。createやdestroyには対応するビューがない (=不要) なので、無駄なビューを作成しないためにここではnewだけを指定しています。7.2のユーザー登録ページのときと同様に、図8.1モックアップを元にセッション新規開始用のログインフォームを作成します。

図8.1: ログインフォームのモックアップ

Usersリソースのときは専用のresourcesメソッドを使用してRESTfulなルーティングを自動的にフルセットで利用できるようにしました (リスト7.3) が、Sessionリソースではフルセットはいらないので、「名前付きルーティング」だけを使用します。この名前付きルーティングでは、GETリクエストやPOSTリクエストをloginルーティングで、DELETEリクエストをlogoutルーティングで扱います。このルーティングを反映したものをリスト8.1に示します。なお、rails generate controllerで生成された不要なルートは、このリストから削除してあります。

Rails.application.routes.draw do
  root                'static_pages#home'
  get    'help'    => 'static_pages#help'
  get    'about'   => 'static_pages#about'
  get    'contact' => 'static_pages#contact'
  get    'signup'  => 'users#new'
  get    'login'   => 'sessions#new'
  post   'login'   => 'sessions#create'
  delete 'logout'  => 'sessions#destroy'
  resources :users
end

リスト8.1で定義したルーティングのURLやアクション (表8.1) は、ユーザー用のURLやアクション (表7.1) とだいたい似ています。

これまでに名前付きルーティングをだいぶ追加してきたので、ここでアプリケーションの全ルーティングを表示できると便利です。rake routesコマンドを実行すればいつでもルーティングのリストを表示できます。

$ bundle exec rake routes
 Prefix Verb   URI Pattern               Controller#Action
     root GET    /                         static_pages#home
     help GET    /help(.:format)           static_pages#help
    about GET    /about(.:format)          static_pages#about
  contact GET    /contact(.:format)        static_pages#contact
   signup GET    /signup(.:format)         users#new
    login GET    /login(.:format)          sessions#new
          POST   /login(.:format)          sessions#create
   logout DELETE /logout(.:format)         sessions#destroy
    users GET    /users(.:format)          users#index
          POST   /users(.:format)          users#create
 new_user GET    /users/new(.:format)      users#new
edit_user GET    /users/:id/edit(.:format) users#edit
     user GET    /users/:id(.:format)      users#show
          PATCH  /users/:id(.:format)      users#update
          PUT    /users/:id(.:format)      users#update
          DELETE /users/:id(.:format)      users#destroy

今はこのルーティングを完全に理解できる必要はありません。それでもこのリストを何となく眺めてみれば、アプリケーションでサポートされている全アクションがこのリストにあることに気付くと思います。

8.1.2 ログインフォーム

コントローラとルーティングを定義したので、今度は新しいセッションで使用するビュー、つまりログインフォームを整えましょう。図8.1と図7.11を比較してみると、ログインフォームとユーザー登録フォームにはほとんど違いがないことがわかります。違いは、4つあったフィールドが [Email] と [Password] の2つに減っていることだけです。

ログインフォームで入力した情報に誤りがあったときは、ログインページをもう一度表示してエラーメッセージを出力します (図8.2)。7.3.3では、エラーメッセージの表示にエラーメッセージ用パーシャル (部分テンプレート) を使用しましたが、そのエラーメッセージはActive Recordによって自動的に表示されていたことを思い出しましょう。セッションはActive Recordオブジェクトではないので、上のようにActive Recordがよしなにエラーメッセージを表示してくれるということは期待できません。そこで、ここではフラッシュメッセージでエラーを表示します。

図8.2 ログイン失敗時のモックアップ

リスト7.13のときは、以下のようにユーザー登録フォームでform_forヘルパーを使用し、ユーザーのインスタンス変数@userを引数にとっていました。

<%= form_for(@user) do |f| %>
  .
  .
  .
<% end %>

セッションフォームとユーザー登録フォームの最大の違いは、セッションにはSessionモデルというものがなく、そのため@userのようなインスタンス変数に相当するものもない点です。従って、新しいセッションフォームを作成するときには、form_forヘルパーに追加の情報を独自に渡さなければなりません。

form_for(@user)

Railsでは上のように書くだけで、「フォームのactionは/usersというURLへのPOSTである」と自動的に判定しますが、セッションの場合はリソースの名前とそれに対応するURLを具体的に指定する必要があります³。

form_for(:session, url: login_path)

適切なform_forを使用することで、リスト7.13のユーザー登録フォームを参考にして、リスト8.2に示したようなモックアップに従ったログインフォームを簡単に作成できます (図8.1)。

<% provide(:title, "Log in") %>
<h1>Log in</h1>

<div class="row">
  <div class="col-md-6 col-md-offset-3">
    <%= form_for(:session, url: login_path) do |f| %>

      <%= f.label :email %>
      <%= f.email_field :email, class: 'form-control' %>

      <%= f.label :password %>
      <%= f.password_field :password, class: 'form-control' %>

      <%= f.submit "Log in", class: "btn btn-primary" %>
    <% end %>

    <p>New user? <%= link_to "Sign up now!", signup_path %></p>
  </div>
</div>

ユーザーがすぐクリックできるように、ユーザー登録ページのリンクを追加してあることにご注目ください。リスト8.2のコードを使用すると、図8.3のようにログインフォームが表示されます ([Log in] リンクがまだ効かないので、自分でブラウザのアドレスバーに「/login」とURLを直接入力してください。ログインリンクは8.2.3で動くようにします)。

図8.3: ログインフォーム

生成されたHTMLフォームをリスト8.3に示します。

<form accept-charset="UTF-8" action="/login" method="post">
  <input name="utf8" type="hidden" value="&#x2713;" />
  <input name="authenticity_token" type="hidden"
         value="NNb6+J/j46LcrgYUC60wQ2titMuJQ5lLqyAbnbAUkdo=" />
  <label for="session_email">Email</label>
  <input class="form-control" id="session_email"
         name="session[email]" type="text" />
  <label for="session_password">Password</label>
  <input id="session_password" name="session[password]"
         type="password" />
  <input class="btn btn-primary" name="commit" type="submit"
       value="Log in" />
</form>

リスト8.3とリスト7.15を比較することで、フォーム送信後にparamsハッシュに入る値が、メールアドレスとパスワードのフィールドにそれぞれ対応したparams[:session][:email]とparams[:session][:password]になることが推測できると思います。

8.1.3 ユーザーの検索と認証

ユーザー登録では最初にユーザーを作成しましたが、ログインでセッションを作成する場合に最初に行うのは、入力が無効な場合の処理です。最初に、フォームが送信されたときの動作を順を追って理解します。次に、ログインが失敗した場合に表示されるエラーメッセージを配置します (モックアップを図8.2に示します)。次に、ログインに成功した場合 (8.2) に使用する土台部分を作成します。ここでは、ログインが送信されるたびに、パスワードとメールアドレスの組み合わせが有効かどうかを判定します。

それでは、最初に最小限のcreateアクションをSessionsコントローラで定義し、空のnewアクションとdestroyアクションもついでに作成しておきましょう (リスト8.4)。リスト8.4のcreateアクションの中では何も行われませんが、アクションを実行するとnewビューが出力されるのでこれで十分です。/sessions/newフォームを送信すると図8.4のようになります。

class SessionsController < ApplicationController

  def new
  end

  def create
    render 'new'
  end

  def destroy
  end
end

図8.4: リスト8.4のcreateで最初に失敗したログイン

図8.4に表示されているデバッグ情報にご注目ください。8.1.2の終わりでも簡単に触れましたが、paramsハッシュでは、以下のようにsessionキーの下にメールアドレスとパスワードがあります。

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

ユーザー登録の場合 (図7.15) と同様、これらのパラメータはリスト4.10に示したようにネストした (入れ子になった) ハッシュになっていました。特に、paramsは以下のような入れ子ハッシュになっています。ハッシュの中にハッシュがある構造です。

{ session: { password: "foobar", email: "user@example.com" } }

これはつまり、

params[:session]

上自体もハッシュであり、以下の要素を含んでいます。

{ password: "foobar", email: "user@example.com" }

その結果、

params[:session][:email]

上はフォームから送信されたメールアドレスであり、

params[:session][:password]

上はフォームから送信されたパスワードです。

要するにcreateアクションの中では、ユーザーの認証に必要なあらゆる情報をparamsハッシュから簡単に取り出せるということです。そして、認証に必要なすべてのメソッドもここまでに学んであります (そうなるように本書を書いたのです)。ここでは、Active Recordが提供するUser.find_byメソッド (6.1.4) と、has_secure_passwordが提供するauthenticateメソッド (6.3.4) を使用します。authenticateメソッドは認証に失敗したときにfalseを返す (6.3.4) ことを思い出しましょう。以上をまとめてユーザーログインを実装したものをリスト8.5に示します。

class SessionsController < ApplicationController

  def new
  end

  def create
    user = User.find_by(email: params[:session][:email].downcase)
    if user && user.authenticate(params[:session][:password])
      # ユーザーログイン後にユーザー情報のページにリダイレクトする
    else
      # エラーメッセージを作成する
      render 'new'
    end
  end

  def destroy
  end
end

ハイライト部分の最初の行 (リスト8.5) では、送信されたメールアドレスを使用して、データベースからユーザーを取り出しています (6.2.5ではメールアドレスをすべて小文字で保存していたことを思い出しましょう。そこでここではdowncaseメソッドを使用して、有効なメールアドレスが入力されたときに確実にマッチするようにしています)。次の行は少しわかりにくいかもしれませんが、Railsプログラミングでは定番の手法です。

user && user.authenticate(params[:session][:password])

&& (論理積) は、取得したユーザーが有効かどうかを決定するのに使用します。Rubyではnilとfalse以外のすべてのオブジェクトは、真偽値ではtrueになる (4.2.3) という性質を考慮すると、&&の前後の値の組み合わせは表8.2のようになります。表8.2を見ると、入力されたメールアドレスを持つユーザーがデータベースに存在し、かつ入力されたパスワードがそのユーザーのパスワードである場合のみ、if文がtrueになることがわかります。言葉でまとめると「ユーザーがデータベースにあり、かつ、認証に成功した場合にのみ」となります。

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

7.3.2では、ユーザー登録のエラーメッセージ表示にUserモデルのエラーメッセージをうまく利用したことを思い出しましょう。ユーザー登録の場合、エラーメッセージは特定のActive Recordオブジェクトに関連付けられていたのでその手が使えました。しかしセッションではActive Recordのモデルを使用していないため、その手が通用しません。そこで、ログインに失敗したときには代わりにフラッシュメッセージを表示することにします。最初のコードをリスト8.6に示します (このコードはわざと少し間違えてあります)。

class SessionsController < ApplicationController

  def new
  end

  def create
    user = User.find_by(email: params[:session][:email].downcase)
    if user && user.authenticate(params[:session][:password])
      # ユーザーログイン後にユーザー情報のページにリダイレクトする
    else
      flash[:danger] = 'Invalid email/password combination' # 本当は正しくない
      render 'new'
    end
  end

  def destroy
  end
end

フラッシュメッセージはWebサイトのレイアウトに表示される (リスト7.25) ので、flash[:danger]で設定したメッセージは自動的に表示されます。Bootstrap CSSのおかげで適切なスタイルも与えられます (図8.5)。

図8.5: ログインに失敗したときのフラッシュメッセージ

本文およびリスト8.6のコメントで述べたように、このコードには誤りがあります。ページにはちゃんとエラーメッセージが表示されていますが、どこが問題なのでしょうか。実は上のコードのままでは、リクエストのフラッシュメッセージが一度表示されると消えずに残ってしまいます。リスト7.24でリダイレクトを使用したときとは異なり、表示したテンプレートをrenderメソッドで強制的に再レンダリングしてもリクエストと見なされないため、リクエストのメッセージが消えません。たとえば、わざと無効な情報を入力して送信してエラーメッセージを表示してから、Homeページをクリックして移動すると、そこでもフラッシュメッセージが表示されたままになっています (図8.6)。この問題は8.1.5で修正します。

図8.6 フラッシュメッセージが消えずに残っている例

8.1.5 フラッシュのテスト

フラッシュメッセージが消えない問題は、このアプリケーションの小さなバグです。コラム3.3で解説したテストガイドラインの教えに従えば、これはまさに「エラーをキャッチするテストを先に書いて、そのエラーが解決するようにコードを書く」に該当する状況です。さっそく、ログインフォームの送信について簡単な統合テストを作成することから始めましょう。この統合テストは、そのままバグのドキュメントにもなり、今後の回帰バグ発生を防止する効能もあります。さらに、今後この統合テストを土台として、より本格的な統合テストを作成するときにも便利です。

アプリケーションのログインの挙動をテストするために、最初に統合テストを生成します。

$ rails generate integration_test users_login
      invoke  test_unit
      create    test/integration/users_login_test.rb

次に、図8.5と図8.6の手順をテストコードで再現する必要があります。基本的な流れを以下に示します。

1. ログイン用のパスを開く
2. 新しいセッションのフォームが正しく表示されたことを確認する
3. わざと無効なparamsハッシュを使用してセッション用パスにPOSTする
4. 新しいセッションのフォームが再度表示され、フラッシュメッセージが追加されることを確認する
5. 別のページ (Homeページなど) にいったん移動する
6. 移動先のページでフラッシュメッセージが表示されていないことを確認する

上のテスト手順の実装をリスト8.7に示します。

require 'test_helper'

class UsersLoginTest < ActionDispatch::IntegrationTest

  test "login with invalid information" do
    get login_path
    assert_template 'sessions/new'
    post login_path, session: { email: "", password: "" }
    assert_template 'sessions/new'
    assert_not flash.empty?
    get root_path
    assert flash.empty?
  end
end

リスト8.7のテストを追加すると、このログインテストはREDになるはずです。

$ bundle exec rake test TEST=test/integration/users_login_test.rb

上のように、引数でTESTにテストファイルのフルパスを与えると、そのテストファイルだけを実行できます。

リスト8.7の失敗するテストをパスさせるには、本編のコードでflashをflash.nowに置き換えます。後者は、レンダリングが終わっているページで特別にフラッシュメッセージを表示することができます。flashのメッセージとは異なり、flash.nowのメッセージはその後リクエストが発生したときに消滅します (リスト8.7ではまさにその手順を再現しています)。置き換えの終わった正しいアプリケーションコードをリスト8.9に示します。

class SessionsController < ApplicationController

  def new
  end

  def create
    user = User.find_by(email: params[:session][:email].downcase)
    if user && user.authenticate(params[:session][:password])
      # ユーザーログイン後にユーザー情報のページにリダイレクトする
    else
      flash.now[:danger] = 'Invalid email/password combination'
      render 'new'
    end
  end

  def destroy
  end
end

続いて、ログインの統合テストを含む全テストスイートを実行してみると、GREENになることを確認できます。

$ bundle exec rake test TEST=test/integration/users_login_test.rb
$ bundle exec rake test

8.2.1 log_inメソッド

Railsで事前定義済みのsessionメソッドを使用して、単純なログインを行えるようにします (なお、これは8.1.1で生成したSessionsコントローラとは無関係ですのでご注意ください)。このsessionメソッドはハッシュのように扱えるので、以下のように代入します。

session[:user_id] = user.id

上のコードを実行すると、ユーザーのブラウザ内の一時cookiesに暗号化済みのユーザーIDが自動で作成されます。この後のページで、session[:user_id]を使用してユーザーIDを元通りに取り出すことができます。一方、cookiesメソッド (8.4) とは対照的に、sessionメソッドで作成された一時cookiesは、ブラウザを閉じた瞬間に有効期限が終了します。

同じログイン手法を様々な場所で使い回せるようにするために、Sessionsヘルパーにlog_inという名前のメソッドを定義することにします (リスト8.12)

module SessionsHelper

  # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end
end

sessionメソッドで作成した一時cookiesは自動的に暗号化され、リスト8.12のコードは保護されます。ただし今回使ったsessionメソッドで作成する「一時セッション」と比べて、次章で取り扱うcookiesメソッドで作成する「永続的セッション」ではより注意深くなる必要があります。cookiesを使った動作には、セッションハイジャックという攻撃を受ける可能性が常につきまとうからです。ユーザーのブラウザ上に保存される情報については、8.4でもう少し注意深く扱うことにします。

リスト8.12でlog_inというヘルパーメソッドを定義できたので、やっと、ユーザーログインを行ってセッションのcreateアクションを完了し、ユーザーのプロフィールページにリダイレクトする準備ができました。作成したコードをリスト8.13に示します⁴。

class SessionsController < ApplicationController

  def new
  end

  def create
    user = User.find_by(email: params[:session][:email].downcase)
    if user && user.authenticate(params[:session][:password])
      log_in user
      redirect_to user
    else
      flash.now[:danger] = 'Invalid email/password combination'
      render 'new'
    end
  end

  def destroy
  end
end

以下の簡単なリダイレクトは、

redirect_to user

7.4.1でも使用しました。Railsでは、自動的に上のコードを変換して、以下のようなユーザープロフィールページへのルーティングします。

user_url(user)

リスト8.13でcreateアクションを定義できたので、8.2で定義したログインフォームも正常に動作するようになったはずです。今はログインしても画面表示が何も変わらないので、ユーザーがログイン中かどうかは、ブラウザセッションを直接確認しない限りわかりません。このままでは困るので、ログインしていることがはっきりわかるようにします。そこで8.2.2では、セッションに含まれるIDを利用して、データベースから現在のユーザー名を取り出して画面で表示する予定です。8.2.3では、アプリケーションのレイアウト上のリンクを変更する予定です。このリンクをクリックすると、現在ログオンしているユーザーのプロフィールが表示されます。

8.2.2 現在のユーザー

ユーザーIDを一時セッションの中に安全に置けるようになったので、今度はそのユーザーIDを別のページで取り出すことにしましょう。そのためには、current_userメソッドを定義して、セッションIDに対応するユーザー名をデータベースから取り出せるようにします。current_userメソッドの目的は、以下のようなコードを書けるようにすることです。

<%= current_user.name %>

以下も同様です。

redirect_to current_user

現在のユーザーを検索する方法のひとつとして思い付くのは、ユーザープロフィールページ (リスト7.5) と同様に、以下のfindメソッドを使用することです。

User.find(session[:user_id])

しかし6.1.4で既に経験済みのとおり、ユーザーIDが存在しない状態でfindを使用すると例外が発生してしまいます。findのこの動作は、ユーザープロフィールページでは完全に適切です。IDが無効の場合は例外を発生してくれなければ困るからです。しかし、ユーザーがログインしていないなど多くの状況では、session[:user_id]の値はnilになります。この状態を修正するために、createメソッド内でメールアドレスの検索に使ったのと同じfind_byメソッドを使うことにします。ただし今度はemailではなくidで検索します。

User.find_by(id: session[:user_id])

今度はIDが無効な場合 (=ユーザーが存在しない場合) にもメソッドは例外を発生せず、nilを返します。

今度はcurrent_userを以下のように定義し直します。

def current_user
  User.find_by(id: session[:user_id])
end

これは正常に動作します。しかし少し残念なのは、current_userがページ内で複数使用されていると、同じ回数だけデータベースも呼び出されてしまうことです。そこで、Rubyの慣習に従って、User.find_byの実行結果をインスタンス変数に保存することにします。こうすることで、データベースの読み出しは最初の一回だけになり、以後の呼び出しではインスタンス変数を返すようになります⁵。地味なようですが、Railsの高速化のために重要なテクニックです。

if @current_user.nil?
  @current_user = User.find_by(id: session[:user_id])
else
  @current_user
end

or演算子「||」(4.2.3) を使用すれば、上の「メモ化」コードを以下のようにたった1行で書けます。

@current_user = @current_user || User.find_by(id: session[:user_id])

ここで重要なのは、Userオブジェクトそのものの論理値は常にtrueになることです。そのおかげで、@current_userに何も代入されていないときだけfind_by呼び出しが実行され、無駄なデータベース読み出しが行われなくなります。

上のコードはひとまず動作しますが、実はまだ「Ruby的に」正しいコードではありません。@current_userへの代入は、Rubyでは以下のような短縮形で書くのが王道です。

@current_user ||= User.find_by(id: session[:user_id])

初めてこの記法を見た方はとまどうかもしれません。しかしRubyではこの「||=」記法は広く使用されています (コラム8.1)。

x = x + 1

x += 1

  $ rails console
  >> x = 1
  => 1
  >> x += 1
  => 2
  >> x *= 3
  => 6
  >> x -= 8
  => -2
  >> x /= 2
  => -1

  >> @foo
  => nil
  >> @foo = @foo || "bar"
  => "bar"
  >> @foo = @foo || "baz"
  => "bar"

  x    =   x   +   1      ->     x     +=   1
  x    =   x   *   3      ->     x     *=   3
  x    =   x   -   8      ->     x     -=   8
  x    =   x   /   2      ->     x     /=   2
  @foo = @foo || "bar"    ->     @foo ||= "bar"

@current_user ||= User.find_by(id: session[:user_id])

前述の簡潔な記法をcurrent_userメソッドに適用した結果をリスト8.14に示します。

module SessionsHelper

  # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end

  # 現在ログインしているユーザーを返す (ユーザーがログイン中の場合のみ)
  def current_user
    @current_user ||= User.find_by(id: session[:user_id])
  end
end

リスト8.14のcurrent_userメソッドが動作するようになったので、ユーザーがログインしているかどうかに応じてアプリケーションの動作を変更するための準備が整いました。

8.2.3 レイアウトリンクを変更する

ログイン機能の最初の具体的な応用として、ユーザーがログインしているときとそうでないときでレイアウトを変更してみましょう。特に、図8.7のモックアップ⁶に示したように、「ログアウト」リンク、「ユーザー設定」リンク、「ユーザーリストを表示」リンク、「現在のユーザープロフィールを表示」リンクも追加します。図8.7では、ログアウトのリンクとプロフィールのリンクは [Account] メニューの項目として表示されている点にご注目ください。リスト8.16では、Bootstrapを使用してこのようなメニューを実現する方法を示します。

図8.7: ログイン成功後のユーザープロフィール画面のモックアップ

筆者なら即、この時点で上のメニューを記述する統合テストを書くでしょう。コラム3.3でも解説したように、Railsのテストツールに習熟するにつれ、何も指示されなくても、筆者のようにこの時点でテストを書きたくなると思います。とはいうものの今は無理は禁物です。このテストではまたいくつか新しいアイディアを投入する必要もあるので、テスト作成は8.2.4に回すことにします。

サイトレイアウトのリンクを変更する方法のひとつとして考えられるのは、ERBコードの中でif-elseを使用し、条件に応じてリンクを表示し分けることです。

<% if logged_in? %>
  # ログインユーザー用のリンク
<% else %>
  # ログインしていないユーザー用のリンク
<% end %>

このコードを書くためには、論理値を返すlogged_in?メソッドが必要なので、まずそれを定義します。

ユーザーがログイン中の状態とは、セッションにユーザーが存在する、つまりcurrent_userがnilでないということです。これをチェックするには否定演算子 (4.2.3)が必要なので、! (参考: 英語ではbangと読みます) を使用します。作成したlogged_in?メソッドをリスト8.15に示します。

module SessionsHelper

  # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end

  # 現在ログインしているユーザーを返す (ユーザーがログイン中の場合のみ)
  def current_user
    @current_user ||= User.find_by(id: session[:user_id])
  end

  # ユーザーがログインしていればtrue、その他ならfalseを返す
  def logged_in?
    !current_user.nil?
  end
end

リスト8.15を追加したので、ユーザーのログイン時にレイアウトを変えられるようにする準備ができました。なお、新しく作るリンクは4つですが、そのうち以下の2つのリンクは当面の間未実装のままとします (第9章で完成の予定)。

<%= link_to "Users",    '#' %>
<%= link_to "Settings", '#' %>

ログアウト用リンクでは、リスト8.1で定義したログアウト用パスを使用します。

<%= link_to "Log out", logout_path, method: :delete %>

上のコードでは、ログアウト用リンクの引数としてハッシュを渡している点にご注目ください。このハッシュでは、HTTPのDELETEリクエスト⁷を使用するよう指示しています。プロフィール用リンクについても同様に以下のようにします。

<%= link_to "Profile", current_user %>

なお、上のコードは以下のように書くこともできます。

<%= link_to "Profile", user_path(current_user) %>

しかしこの状況ではcurrent_userを使う方が、Railsによってuser_path(current_user)され、ユーザープロフィールへのリンクが自動的に実現できるのでずっと便利です。そしてユーザーがログインしていない場合は、リスト8.1のログイン用パスを使用して、以下のようにログインフォームへのリンクを作成します。

<%= link_to "Log in", login_path %>

以上をすべてヘッダーのパーシャル部分に適用して更新したものをリスト8.16に示します。

<header class="navbar navbar-fixed-top navbar-inverse">
  <div class="container">
    <%= link_to "sample app", root_path, id: "logo" %>
    <nav>
      <ul class="nav navbar-nav navbar-right">
        <li><%= link_to "Home", root_path %></li>
        <li><%= link_to "Help", help_path %></li>
        <% if logged_in? %>
          <li><%= link_to "Users", '#' %></li>
          <li class="dropdown">
            <a href="#" class="dropdown-toggle" data-toggle="dropdown">
              Account <b class="caret"></b>
            </a>
            <ul class="dropdown-menu">
              <li><%= link_to "Profile", current_user %></li>
              <li><%= link_to "Settings", '#' %></li>
              <li class="divider"></li>
              <li>
                <%= link_to "Log out", logout_path, method: "delete" %>
              </li>
            </ul>
          </li>
        <% else %>
          <li><%= link_to "Log in", login_path %></li>
        <% end %>
      </ul>
    </nav>
  </div>
</header>

レイアウトに新しいリンクを追加したので、リスト8.16にBootstrapのドロップダウンメニュー機能⁸を適用できる状態になりました。具体的には、BootstrapのCSSのdropdownクラスやdropdown-menuなどをインクルードします。ドロップダウンを実際に有効にするには、Railsのアセットパイプライン用のapplication.jsファイルでBootstrapのカスタムJavaScriptライブラリをインクルードします (リスト8.17)。

//= require jquery
//= require jquery_ujs
//= require bootstrap
//= require turbolinks
//= require_tree .

この時点で、ログインパスにアクセスして有効なユーザーとしてログインできるようになっているので、これまでの3つの節⁹のコードを効率よくテストできるようになります。リスト8.16やリスト8.17のコードにより、図8.8のようにドロップダウンメニューとログイン中ユーザー用のリンクが表示されます。ブラウザを完全に終了すると、期待どおりアプリケーションのログインステータスが消去され、再びログインを要求されるようになったことを確認できます。

図8.8: ドロップダウンメニューと新しいリンクが表示されたログイン中のユーザー

8.2.4 レイアウトの変更をテストする

アプリケーションでのログイン成功を手動で確認したので、先に進む前に統合テストを書いてこの動作をテストで表現し、今後の回帰バグの発生をキャッチできるようにしましょう。リスト8.7を元にテストを作成し、以下の操作手順をテストで記述して確認できるようにします。

1. ログイン用のパスを開く
2. セッション用パスに有効な情報をpostする
3. ログイン用リンクが表示されなくなったことを確認する
4. ログアウト用リンクが表示されていることを確認する
5. プロフィール用リンクが表示されていることを確認する

上の変更を確認するためには、テスト時に登録済みユーザーとしてログインしておく必要があります。当然ながら、データベースにそのためのユーザーが登録されていなければなりません。Railsでは、このようなテスト用データをフィクスチャで作成できます。フィクスチャを使用して、テストに必要なデータをtestデータベースに読み込んでおくことができます。6.2.5では、メールの一意性テスト (リスト6.30) がパスするためにデフォルトのフィクスチャを削除する必要がありました。今度は自分で空のフィクスチャファイルを作成してデータを追加しましょう。

現時点のテストでは、ユーザーはひとりいれば十分です。そのユーザーには有効な名前と有効なメールアドレスを設定しておきます。テスト中にそのユーザーとして自動ログインするために、そのユーザーの有効なパスワードも用意して、Sessionsコントローラのcreateアクションに送信されたパスワードと比較できるようにする必要があります。図6.8のデータモデルをもう一度見てみると、password_digest属性をユーザーのフィクスチャに追加すればよいことがわかります。そのために、digestメソッドを独自に定義することにします。

6.3.1で説明したように、has_secure_passwordでbcryptパスワードが作成されるので、同じ方法でフィクスチャ用パスワードを作成します。Railsのsecure_passwordのソースコードを調べてみると、以下のメソッドがあります。

BCrypt::Password.create(string, cost: cost)

stringはハッシュ化する文字列、costはコストパラメータと呼ばれる値です。コストパラメータでは、ハッシュを算出するための計算コストを指定します。コストパラメータの値を高くすれば、ハッシュからオリジナルのパスワードを計算で推測することが困難になりますので、production環境ではセキュリティ上重要です。しかしテスト中はコストを高くする意味はないので、digestメソッドの計算はなるべく軽くしておきます。secure_passwordのソースコードには以下の行があります。

cost = ActiveModel::SecurePassword.min_cost ? BCrypt::Engine::MIN_COST :
                                              BCrypt::Engine.cost

少々込み入っていますが、コストパラメータをテスト中は最小にし、production環境ではnormal (high) にする方法がわかれば十分です。「?」〜「:」という記法については8.4.5で解説します。

digestメソッドは他にも様々な場所で使用できます。8.4.1ではdigestをUserモデルで再利用します。そこでは、digestメソッドをuser.rbに置くことをすすめています。ダイジェストの計算はユーザーごとに行わなければならないものではないので、フィクスチャファイルなどでわざわざユーザーオブジェクトにアクセスする必然性はありません。そこで、digestメソッドをUserクラス自身に配置してクラスメソッドにすることにしましょう (クラスメソッドの作り方については4.4.1で簡単に説明しました)。変更の結果をリスト8.18に示します。

class User < ActiveRecord::Base
  before_save { self.email = email.downcase }
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX },
                    uniqueness: { case_sensitive: false }
  has_secure_password
  validates :password, presence: true, length: { minimum: 6 }

  # 与えられた文字列のハッシュ値を返す
  def User.digest(string)
    cost = ActiveModel::SecurePassword.min_cost ? BCrypt::Engine::MIN_COST :
                                                  BCrypt::Engine.cost
    BCrypt::Password.create(string, cost: cost)
  end
end

リスト8.18のdigestメソッドができたので、有効なユーザーを表すユーザーフィクスチャを作成できるようになりました (リスト8.19)。

michael:
  name: Michael Example
  email: michael@example.com
  password_digest: <%= User.digest('password') %>

フィクスチャではERBを利用できる点にご注目ください。

<%= User.digest('password') %>

上のERBコードでテストユーザー用の有効なパスワードを作成できます。

has_secure_passwordで必要となるpassword_digest属性はこれで準備できましたが、ハッシュ化されていない生のパスワードも参照できると便利です。しかし残念なことに、フィクスチャではこのようなことはできません。さらに、リスト8.19にpassword属性を追加すると、そのようなカラムはデータベースに存在しないというエラーが発生します。実際、データベースにはそんなカラムはありません。この状況を切り抜けるために、テスト用のフィクスチャユーザーでは全員同じパスワード「password」を使用することにします。これはフィクスチャでよく使われる手法です。

有効なユーザーのフィクスチャを作成できたので、テストで以下のようにフィクスチャデータを参照できます。

user = users(:michael)

上のusersはフィクスチャのファイル名users.ymlを表し、:michaelというシンボルはリスト8.19のユーザーを参照するためのキーを表します。

フィクスチャのユーザーにアクセスできるようになったので、レイアウトのリンクをテストできる状態になりました。レイアウトのリンクをテストするには、前述の操作手順をテストコードに書き換えます (リスト8.20)。

require 'test_helper'

class UsersLoginTest < ActionDispatch::IntegrationTest

  def setup
    @user = users(:michael)
  end
  .
  .
  .
  test "login with valid information" do
    get login_path
    post login_path, session: { email: @user.email, password: 'password' }
    assert_redirected_to @user
    follow_redirect!
    assert_template 'users/show'
    assert_select "a[href=?]", login_path, count: 0
    assert_select "a[href=?]", logout_path
    assert_select "a[href=?]", user_path(@user)
  end
end

上のコードのうち、以下の行は

assert_redirected_to @user

リダイレクト先が正しいかどうかをチェックします。

follow_redirect!

上の行では、実際にそのページに移動します。リスト8.20では、ログイン用リンクが表示されなくなったことも確認しています。このチェックは、ログインパスのリンクがページにないかどうかで判定しています。

assert_select "a[href=?]", login_path, count: 0

count: 0というオプションをアサーションに追加すると、渡したパターンに一致するリンクがゼロになっているかどうかを確認するようassert_selectに指示します。なお、リスト5.25では、count: 2を使用してリンクが2つあるかどうかを確認しているので、比較してみるとよいでしょう。

アプリケーションのコードは既に動作するようになっているので、ここでテストを実行するとGREENになるはずです。

$ bundle exec rake test TEST=test/integration/users_login_test.rb \
>                       TESTOPTS="--name test_login_with_valid_information"

上のコマンドでは、指定したテストファイル内にある特定のテストだけを実行するために、以下のオプションを追加してあります。

TESTOPTS="--name test_login_with_valid_information"

(上記の2行目にある '>' という文字は、改行を示すためにシェルが自動的に挿入する文字です。手動で入力しないよう、注意してください。) 上のオプションは、テスト名を指定するときに使うオプションです。なお、指定するテスト名は、接頭語の「test_」と、テストの説明文の単語をアンダースコアでつないだ文字列で表します。

8.2.5 ユーザー登録時にログイン

以上で認証システムが動作するようになりましたが、今のままでは、登録の終わったユーザーがデフォルトではログインしていないので、ユーザーがとまどう可能性があります。ユーザー登録が終わってからユーザーに手動ログインを促すと、ユーザーに余分な手順を強いることになるので、ユーザー登録中にログインを済ませておくことにします。ユーザー登録中にログインするには、Usersコントローラのcreateアクションにlog_inを追加するだけで済みます (リスト8.22)¹⁰。

class UsersController < ApplicationController

  def show
    @user = User.find(params[:id])
  end

  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)
    if @user.save
      log_in @user
      flash[:success] = "Welcome to the Sample App!"
      redirect_to @user
    else
      render 'new'
    end
  end

  private

    def user_params
      params.require(:user).permit(:name, :email, :password,
                                   :password_confirmation)
    end
end

リスト8.22の動作をテストするために、リスト7.26のテストに1行追加して、ユーザーがログイン中かどうかをチェックします。そのために、リスト8.15で定義したlogged_in?ヘルパーメソッドとは別に、is_logged_in?ヘルパーメソッドを定義しておくと便利です。このヘルパーメソッドは、テストのセッションにユーザーがあればtrueを返し、それ以外の場合はfalseを返します (リスト8.23)。残念ながらヘルパーメソッドはテストから呼び出せないので、リスト8.15のようにcurrent_userを呼び出せません。sessionメソッドはテストでも利用できるので、これを代わりに使用します。ここでは取り違えを防ぐため、logged_in?の代わりにis_logged_in?を使用して、ヘルパーメソッド名がテストヘルパーとSessionヘルパーで同じにならないようにしておきます¹¹。

ENV['RAILS_ENV'] ||= 'test'
.
.
.
class ActiveSupport::TestCase
  fixtures :all

  # テストユーザーがログインしていればtrueを返す
  def is_logged_in?
    !session[:user_id].nil?
  end
end

リスト8.23のコードを使用すると、ユーザー登録の終わったユーザーがログイン状態になっているかどうかを確認できます (リスト8.24)。

require 'test_helper'

class UsersSignupTest < ActionDispatch::IntegrationTest
  .
  .
  .
  test "valid signup information" do
    get signup_path
    assert_difference 'User.count', 1 do
      post_via_redirect users_path, user: { name:  "Example User",
                                            email: "user@example.com",
                                            password:              "password",
                                            password_confirmation: "password" }
    end
    assert_template 'users/show'
    assert is_logged_in?
  end
end

これで、テストを実行するとGREENになるはずです。

$ bundle exec rake test

8.4.1 記憶トークンと暗号化

8.2では、Railsのsessionメソッドを使用してユーザーIDを保存しましたが、この情報はブラウザを閉じると消えてしまいます。本節では、セッションの永続化の第一歩として記憶トークン (remember token) を生成し、cookiesメソッドによる永続的cookiesの作成や、安全性の高い記憶ダイジェスト (remember digest) によるトークン認証にこの記憶トークンを活用します。

8.2.1で解説したように、sessionメソッドで保存した情報は自動的に安全が保たれますが、cookiesメソッドに保存する情報は残念ながらそのようにはなっていません。特に、cookiesを永続化するとセッションハイジャックという攻撃を受ける可能性があります。この攻撃は、記憶トークンを奪って、特定のユーザーになりすましてログインするというものです。cookiesを盗み出す有名な方法は4とおりあります。(1) 管理の甘いネットワークを通過するネットワークパケットからパケットスニッファという特殊なソフトウェアで直接cookieを取り出す¹⁴。(2) データベースから記憶トークンを取り出す。(3) クロスサイトスクリプティング (XSS) を使う。(4) ユーザーがログインしているパソコンやスマホを直接操作してアクセスを奪い取る。7.5では、最初の問題を防止するためにSecure Sockets Layer (SSL) をサイト全体に適用して、ネットワークデータを暗号化で保護し、パケットスニッファから読み取られないようにしています。2番目の問題の対策としては、記憶トークンをそのままデータベースに保存するのではなく、記憶トークンのハッシュ値を保存するようにします。これは、6.3で生のパスワードをデータベースに保存する代わりにパスワードのダイジェストを保存したのと同じコンセプトです。3 番目の問題については、Railsによって自動的に対策が行われます。具体的には、ビューテンプレートで入力した内容をすべて自動的にエスケープします。4番目のログイン中のコンピュータへの物理アクセスによる攻撃については、さすがにシステム側での根本的な防衛手段を講じることは不可能なのですが、ユーザーがログアウトしたときにトークンを必ず変更し、機密上重要になる可能性のある情報をブラウザに表示するときには暗号による署名を行うようにすることで、物理アクセスによる攻撃を最小限に留めるようにします。

上で説明した設計やセキュリティ上の考慮事項を元に、以下の方針で永続的セッションを作成することにします。

1. 記憶トークンにはランダムな文字列を生成して用いる。
2. ブラウザのcookiesにトークンを保存するときには、有効期限を設定する。
3. トークンはハッシュ値に変換してからデータベースに保存する。
4. ブラウザのcookiesに保存するユーザーIDは暗号化しておく。
5. 永続ユーザーIDを含むcookiesを受け取ったら、そのIDでデータベースを検索し、記憶トークンのcookiesがデータベース内のハッシュ値と一致することを確認する。

上の最後の手順が、ユーザーログインのときの手順と似ていることにご注目ください。ユーザーログインでは、メールアドレスをキーにしてユーザーを取り出し、送信されたパスワードがパスワードダイジェストと一致することを (authenticateメソッドで) 確認します (リスト8.5)。つまり、ここでの実装はhas_secure_passwordと似た側面を持ちます。

それでは最初に、必要となるremember_digest属性をUserモデルに追加します (図8.9)。

図8.9: remember_digest属性を追加したUserモデル

図8.9のデータモデルをアプリケーションに追加するために、以下のマイグレーションを生成します。

$ rails generate migration add_remember_digest_to_users remember_digest:string

(6.3.1のパスワードダイジェストのときのマイグレーションと比較してみましょう)。前回のマイグレーションと同様、今回のマイグレーション名も_to_usersで終わっています。これは、マイグレーションの対象がデータベースのusersテーブルであることをRailsに指示するためのものです。今回は種類=stringのremember_digest属性を追加しているので、いつものようにRailsによってデフォルトのマイグレーションが作成されます (リスト8.30)。

class AddRememberDigestToUsers < ActiveRecord::Migration
  def change
    add_column :users, :remember_digest, :string
  end
end

記憶ダイジェストはユーザーが直接読み出すことはないので (かつ、そうさせてはならないので)、remember_digestカラムにインデックスを追加する必要はありません。従って、上のマイグレーションは変更せずにそのまま使用します。

$ bundle exec rake db:migrate

ここで、記憶トークンとして何を使用するかを決める必要があります。有力な候補として様々なものが考えられますが、基本的には長くてランダムな文字列であればどんなものでも構いません。Ruby標準ライブラリのSecureRandomモジュールにあるurlsafe_base64メソッドならこの用途にぴったりです¹⁵。このメソッドは、A–Z、a–z、0–9、“-”、“_”のいずれかの文字 (64種類) からなる長さ22のランダムな文字列を返します (そのためbase64と呼ばれています)。典型的なbase64の文字列は、次のようなものです。

$ rails console
>> SecureRandom.urlsafe_base64
=> "q5lt38hQDc_959PVoo6b7A"

2人のユーザーのパスワードが完全に同じであれば¹⁶、記憶トークンが一意である必然性はなくなりますが、現実にはそんなことはないので、記憶トークンによってセキュリティが高められます¹⁷。上のbase64文字列では、22個の文字でそれぞれ64種類の文字が使用される可能性があり、2つの記憶トークンがたまたま完全に一致する (=衝突する) 確率は64のマイナス16乗、2のマイナス96乗 (10のマイナス29乗) にほぼ等しく、トークンが衝突することはまずありません。さらにありがたいことに、base64はURLを安全にエスケープするためにも用いられる (urlsafe_base64という名前のメソッドがあることからもわかります) ので、base64を採用すれば、第10章でアカウントの有効化のリンクやパスワードリセットのリンクでも同じトークンジェネレータを使用できるようになります。

ユーザーを記憶するには、記憶トークンを作成して、そのトークンをダイジェストに変換したものをデータベースに保存します。フィクスチャをテストするときにdigestメソッドを既に作成してあったので (リスト8.18)、上の結論に従って、新しいトークンを作成するためのnew_tokenメソッドを作成できます。この新しいdigestメソッドではユーザーオブジェクトが不要なので、このメソッドもUserモデルのクラスメソッドとして作成することにします¹⁸。以上を反映したUserモデルをリスト8.31に示します。

class User < ActiveRecord::Base
  before_save { self.email = email.downcase }
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX },
                    uniqueness: { case_sensitive: false }
  has_secure_password
  validates :password, presence: true, length: { minimum: 6 }

  # 与えられた文字列のハッシュ値を返す
  def User.digest(string)
    cost = ActiveModel::SecurePassword.min_cost ? BCrypt::Engine::MIN_COST :
                                                  BCrypt::Engine.cost
    BCrypt::Password.create(string, cost: cost)
  end

  # ランダムなトークンを返す
  def User.new_token
    SecureRandom.urlsafe_base64
  end
end

さしあたっての実装計画としては、user.rememberメソッドを作成することにします。このメソッドは、記憶トークンをユーザーと関連付け、トークンに対応する記憶ダイジェストをデータベースに保存します。リスト8.30のマイグレーションを行ってあるので、Userモデルには既にremember_digest属性が追加されていますが、remember_token属性はまだ追加されていません。そこで、user.remember_tokenメソッド (cookiesの保存場所です) を使用してトークンにアクセスできるようにする必要があります。しかも、トークンをデータベースに保存せずに実装する必要があります。そのためには、6.3の安全なパスワードの問題のときと同様の手法でこれを解決します。あのときは、「仮想の」password属性と、データベース上のセキュアなpassword_digest属性を使用しました。仮想のpassword属性はhas_secure_passwordメソッドで自動的に作成できましたが、今回はremember_tokenのコードを自分で書く必要があります。これを行うには、4.4.5で行ったようにattr_accessorを使用してアクセス可能な属性を作成します。

class User < ActiveRecord::Base
  attr_accessor :remember_token
  .
  .
  .
  def remember
    self.remember_token = ...
    update_attribute(:remember_digest, ...)
  end
end

rememberメソッドの1行目の代入にご注目ください。selfというキーワードを使用しないと、Rubyによってremember_tokenという名前のローカル変数が作成されてしまいます。この動作は、Rubyにおけるオブジェクト内部への要素代入の仕様によるものです。今欲しいのはローカル変数ではありません。selfキーワードを与えると、この代入によってユーザーのremember_token属性が期待どおりに設定されます (リスト6.31の他のbefore_saveコールバックで、emailではなくself.emailと記述していた理由が、これでおわかりいただけたと思います)。rememberメソッドの次の行では、update_attributeメソッドで記憶ダイジェストを更新しています (6.1.5で説明したように、このメソッドはバリデーションを素通りさせます。ここではユーザーのパスワードやパスワード確認にアクセスできないので、バリデーションを素通りさせなければなりません)。

以上の点を考慮して、有効なトークンとそれに関連するダイジェストを作成できるようにします。具体的には、最初にUser.new_tokenで記憶トークンを作成し、続いてUser.digestを適用した結果で記憶ダイジェストを更新します。rememberメソッドの更新結果をリスト8.32に示します。

class User < ActiveRecord::Base
  attr_accessor :remember_token
  before_save { self.email = email.downcase }
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX },
                    uniqueness: { case_sensitive: false }
  has_secure_password
  validates :password, presence: true, length: { minimum: 6 }

  # 与えられた文字列のハッシュ値を返す
  def User.digest(string)
    cost = ActiveModel::SecurePassword.min_cost ? BCrypt::Engine::MIN_COST :
                                                  BCrypt::Engine.cost
    BCrypt::Password.create(string, cost: cost)
  end

  # ランダムなトークンを返す
  def User.new_token
    SecureRandom.urlsafe_base64
  end

  # 永続的セッションで使用するユーザーをデータベースに記憶する
  def remember
    self.remember_token = User.new_token
    update_attribute(:remember_digest, User.digest(remember_token))
  end
end

8.4.2 ログイン状態の保持

user.rememberメソッドが動作するようになったので、ユーザーの暗号化済みIDと記憶トークンをブラウザの永続cookiesに保存して、永続セッションを作成する準備ができました。これを実際に行うにはcookiesメソッドを使用します。このメソッドは、sessionのときと同様にハッシュとして扱えます。個別のcookiesは、ひとつのvalue (値) と、オプションのexpires (有効期限) からできています。有効期限は省略可能です。たとえば以下のように、20年後に期限切れになる記憶トークンと同じ値をcookieに保存することで、永続的なセッションを作ることができます。

cookies[:remember_token] = { value:   remember_token,
                             expires: 20.years.from_now.utc }

(上のコードではRailsの便利なtimeヘルパーを使用しています。コラム8.2を参照してください)。上のように20年で期限切れになるcookies設定はよく使われるようになり、今ではRailsにも特殊なpermanentという専用のメソッドが追加されたほどです。このメソッドを使用すると、コードは以下のようにシンプルになります。

cookies.permanent[:remember_token] = remember_token

上のコードによって、Railsは自動的に期限を20.years.from_nowに設定します。

  $ rails console
  >> 1.year.from_now
  => Sun, 09 Aug 2015 16:48:17 UTC +00:00
  >> 10.weeks.ago
  => Sat, 31 May 2014 16:48:45 UTC +00:00

  >> 1.kilobyte
  => 1024
  >> 5.megabytes
  => 5242880

ユーザーIDをcookiesに保存するには、sessionメソッドで使用したのと同じパターン (リスト8.12) を使用します。具体的には以下のようになります。

cookies[:user_id] = user.id

しかしこのままではIDが生のテキストとしてcookiesに保存されてしまうので、アプリケーションのcookiesの形式が見え見えになってしまい、攻撃者がユーザーアカウントを奪い取ることを助けてしまう可能性があります。これを避けるために、署名付きcookieを使用します。これは、cookieをブラウザに保存する前に安全に暗号化するためのものです。

cookies.signed[:user_id] = user.id

ユーザーIDと永続記憶トークンはペアで扱う必要があるので、cookieも永続化しなくてはなりません。そこで、以下のようにsignedメソッドとpermanentメソッドをチェイン (連鎖) して使用します。

cookies.permanent.signed[:user_id] = user.id

cookiesを設定すると、以後のページのビューで以下のようにしてcookiesからユーザーを取り出せるようになります。

User.find_by(id: cookies.signed[:user_id])

cookies.signed[:user_id]では自動的にユーザーIDのcookiesの暗号が解除され、元に戻ります。続いてbcryptを使用し、cookies[:remember_token]がremember_digestと一致することを確認します (リスト8.32)。ところで、署名されたユーザーIDがあれば記憶トークンは不要なのではないかと疑問に思う方もいるかもしれません。しかし記憶トークンがなければ、暗号化されたIDを奪った攻撃者は、暗号化IDをそのまま使ってお構いなしにログインしてしまうでしょう。現在の設計では、攻撃者が仮に両方のcookiesを奪い取ることに成功したとしても、本物のユーザーがログアウトするとログインできないようになっています。

パズルもいよいよ最後のピースを残すだけとなりました。渡されたトークンがユーザーの記憶ダイジェストと一致することを確認します。この一致をbcryptで確認するための様々な方法があります。secure_passwordのソースコードを調べてみると、以下のような比較を行っている箇所があります¹⁹。

BCrypt::Password.new(password_digest) == unencrypted_password

今回の場合、上のコードを参考に下のようなコードを使用します。

BCrypt::Password.new(remember_digest) == remember_token

このコードをじっくり調べてみると、実に奇妙なつくりになっています。bcryptで暗号化されたパスワードを、トークンと直接比較しています。ということは、==で比較する際にダイジェストを復号化しているのでしょうか。しかし、bcryptのハッシュは復号化できないはずなので、復号化しているはずはありません。そこでbcrypt gemのソースコードを詳しく調べてみると、なんと、比較に使用している==演算子が再定義されています。実際の比較をコードで表すと、以下のようになっています。

BCrypt::Password.new(remember_digest).is_password?(remember_token)

実際の比較では、==の代わりにis_password?という論理値メソッドが使用されています。これで少し見えてきました。今から書くアプリケーションコードでもこれと同じ方法を使用することにしましょう。

以上の説明を元に、ダイジェストトークンの比較をUserモデルのauthenticated?メソッドの中に置けばよいのではないかと推測できます。このメソッドは、has_secure_passwordで提供されるユーザー認証用のauthenticateメソッドと似ています (リスト8.13)。この実装結果をリスト8.33に示します。ところで、このauthenticated?メソッド (リスト8.33) は記憶ダイジェストと強く結びついていますが、実は他の様々な用途にも応用できます。第10章ではこのメソッドを一般化してみます。

class User < ActiveRecord::Base
  attr_accessor :remember_token
  before_save { self.email = email.downcase }
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX },
                    uniqueness: { case_sensitive: false }
  has_secure_password
  validates :password, presence: true, length: { minimum: 6 }

  # 与えられた文字列のハッシュ値を返す
  def User.digest(string)
    cost = ActiveModel::SecurePassword.min_cost ? BCrypt::Engine::MIN_COST :
                                                  BCrypt::Engine.cost
    BCrypt::Password.create(string, cost: cost)
  end

  # ランダムなトークンを返す
  def User.new_token
    SecureRandom.urlsafe_base64
  end

  # 永続的セッションで使用するユーザーをデータベースに記憶する
  def remember
    self.remember_token = User.new_token
    update_attribute(:remember_digest, User.digest(remember_token))
  end

  # 渡されたトークンがダイジェストと一致したらtrueを返す
  def authenticated?(remember_token)
    BCrypt::Password.new(remember_digest).is_password?(remember_token)
  end
end

リスト8.33で定義されているauthenticated?メソッド内のremember_tokenの引数は、リスト8.32のattr_accessor :remember_tokenで定義されているアクセサと同じではない点にご注意ください。引数は、メソッド内ローカルな変数になっていますが、記憶トークンを参照しているので問題ありません。メソッドの引数と同じ名前を使用することはよくあります。もうひとつ、remember_digestの属性の使用法にご注目ください。この使用法はself.remember_digestと同じであり、第6章のnameやemailの使用法とも似ています。remember_digestの属性は、データベースのカラムに対応してActive Recordによって自動的に作成されます (リスト8.30)。

これで、ログインユーザーの記憶処理を作る準備が整いました。rememberヘルパーメソッドを追加して、log_inと連携させます (リスト8.34)。

class SessionsController < ApplicationController

  def new
  end

  def create
    user = User.find_by(email: params[:session][:email].downcase)
    if user && user.authenticate(params[:session][:password])
      log_in user
      remember user
      redirect_to user
    else
      flash.now[:danger] = 'Invalid email/password combination'
      render 'new'
    end
  end

  def destroy
    log_out
    redirect_to root_url
  end
end

log_inのときと同様に、リスト8.34では実際のSessionsヘルパーの動作は、rememberメソッド定義のuser.rememberを呼び出すまで遅延され、そこで記憶トークンを生成してトークンのダイジェストをデータベースに保存します。続いて上と同様に、cookiesメソッドでユーザーIDと記憶トークンの永続cookiesを作成します。変更結果をリスト8.35に示します。

module SessionsHelper

  # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end

  # ユーザーを永続的セッションに記憶する
  def remember(user)
    user.remember
    cookies.permanent.signed[:user_id] = user.id
    cookies.permanent[:remember_token] = user.remember_token
  end

  # 現在ログインしているユーザーを返す (ユーザーがログイン中の場合のみ)
  def current_user
    @current_user ||= User.find_by(id: session[:user_id])
  end

  # ユーザーがログインしていればtrue、その他ならfalseを返す
  def logged_in?
    !current_user.nil?
  end

  # 現在のユーザーをログアウトする
  def log_out
    session.delete(:user_id)
    @current_user = nil
  end
end

リスト8.35のコードでは、ログインするユーザーはブラウザで有効な記憶トークンを得られるように記憶されますが、リスト8.14で定義したcurrent_userメソッドでは一時セッションしか扱っていないので、このままでは正常に動作しません。

@current_user ||= User.find_by(id: session[:user_id])

永続セッションの場合は、session[:user_id]が存在すれば一時セッションからユーザーを取り出し、それ以外の場合はcookies[:user_id]からユーザーを取り出して、対応する永続セッションにログインする必要があります。これを行うには、以下のように記述します。

if session[:user_id]
  @current_user ||= User.find_by(id: session[:user_id])
elsif cookies.signed[:user_id]
  user = User.find_by(id: cookies.signed[:user_id])
  if user && user.authenticated?(cookies[:remember_token])
    log_in user
    @current_user = user
  end
end

上のコードでもuser && user.authenticated (リスト8.5) を使用している点にご注目ください。上のコードは動作しますが、今のままではsessionもcookiesもそれぞれ2回使用されてしまい、無駄です。これを解消するには、次のようにします。

if (user_id = session[:user_id])
  @current_user ||= User.find_by(id: user_id)
elsif (user_id = cookies.signed[:user_id])
  user = User.find_by(id: user_id)
  if user && user.authenticated?(cookies[:remember_token])
    log_in user
    @current_user = user
  end
end

上のコードでは、よく使われる以下のような構造が使用されていますが、少し紛らわしい点があります。

if (user_id = session[:user_id])

一見、上のコードは比較を行っているように見えますが、これは比較ではありません。比較であれば==を使用するはずですが、ここでは代入を行っています。このコードを言葉で表すと、「ユーザーIDがユーザーIDのセッションと等しければ...」ではなく、「(ユーザーIDにユーザーIDのセッションを代入した結果) ユーザーIDのセッションが存在すれば」となります²⁰。

前述のようにcurrent_userヘルパーを定義すると、リスト8.36のようになります。

module SessionsHelper

  # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end

  # ユーザーを永続的セッションに記憶する
  def remember(user)
    user.remember
    cookies.permanent.signed[:user_id] = user.id
    cookies.permanent[:remember_token] = user.remember_token
  end

  # 記憶トークンcookieに対応するユーザーを返す
  def current_user
    if (user_id = session[:user_id])
      @current_user ||= User.find_by(id: user_id)
    elsif (user_id = cookies.signed[:user_id])
      user = User.find_by(id: user_id)
      if user && user.authenticated?(cookies[:remember_token])
        log_in user
        @current_user = user
      end
    end
  end

  # ユーザーがログインしていればtrue、その他ならfalseを返す
  def logged_in?
    !current_user.nil?
  end

  # 現在のユーザーをログアウトする
  def log_out
    session.delete(:user_id)
    @current_user = nil
  end
end

リスト8.36のコードでは、新しくログインしたユーザーは正しく記憶されます。実際にログインしてからブラウザを閉じ、アプリケーションを再起動してからもう一度ブラウザでアプリケーションを開いてみると、期待どおり動作していることを確認できます。その気になれば、ブラウザのcookiesをブラウザで直接調べて結果を確認することもできます (図8.10)²¹。

図8.10: ブラウザに記憶トークンのcookiesを表示する

アプリケーションに現在残された問題はあと1つだけです。ブラウザのcookiesを削除する手段が未実装なので (20年待てば消えますが)、ユーザーがログアウトできません。これは当然テストスイートでキャッチすべき問題であり、REDにならなければなりません。

$ bundle exec rake test

8.4.3 ユーザーを忘れる

ユーザーがログアウトできるようにするために、ユーザーを記憶するためのメソッドと同様の方法で、ユーザーを忘れるためのメソッドを定義します。このuser.forgetメソッドによって、user.rememberが取り消されます。具体的には、記憶ダイジェストをnilで更新します (リスト8.38)。

class User < ActiveRecord::Base
  attr_accessor :remember_token
  before_save { self.email = email.downcase }
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX },
                    uniqueness: { case_sensitive: false }
  has_secure_password
  validates :password, presence: true, length: { minimum: 6 }

  # 与えられた文字列のハッシュ値を返す
  def User.digest(string)
    cost = ActiveModel::SecurePassword.min_cost ? BCrypt::Engine::MIN_COST :
                                                  BCrypt::Engine.cost
    BCrypt::Password.create(string, cost: cost)
  end

  # ランダムなトークンを返す
  def User.new_token
    SecureRandom.urlsafe_base64
  end

  # 永続的セッションで使用するユーザーをデータベースに記憶する
  def remember
    self.remember_token = User.new_token
    update_attribute(:remember_digest, User.digest(remember_token))
  end

  # 渡されたトークンがダイジェストと一致したらtrueを返す
  def authenticated?(remember_token)
    BCrypt::Password.new(remember_digest).is_password?(remember_token)
  end

  # ユーザーログインを破棄する
  def forget
    update_attribute(:remember_digest, nil)
  end
end

リスト8.38のコードを使用すると、永続セッションを終了できるようになる準備が整います。終了するには、forgetヘルパーメソッドを追加してlog_outヘルパーメソッドから呼び出します (リスト8.39)。リスト8.39を見ると、forgetヘルパーメソッドではuser.forgetを呼んでからuser_idとremember_token cookiesを削除していることがわかります。

module SessionsHelper

  # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end
  .
  .
  .
  # 永続的セッションを破棄する
  def forget(user)
    user.forget
    cookies.delete(:user_id)
    cookies.delete(:remember_token)
  end

  # 現在のユーザーがログアウトする
  def log_out
    forget(current_user)
    session.delete(:user_id)
    @current_user = nil
  end
end

8.4.4 ２つの目立たないバグ

実は小さなバグが2つ残っています。2つのバグは互いに強く関連しています。1つ目の地味な問題です。ユーザーは場合によっては、同じサイトを複数のウィンドウ (あるいはタブ) で開いていることもあります。ログアウト用リンクはログイン中には表示されませんが、現在のcurrent_userの使用法では、ユーザーが1つのウィンドウでログアウトすると、もう1つのウィンドウでログアウトしたときにエラーになります リスト8.39)²²。これは、もう1つのウィンドウにある "Log out" リンクをクリックすると、current_userが既にnilとなってしまうため、log_outメソッド内のforget(current_user)が失敗してしまうからです。この問題を回避するためには、ユーザーがログイン中の場合にのみログアウトさせる必要があります。

2番目の地味な問題は、ユーザーが複数のブラウザ (ChromeやFirefoxなど) でログインしていたときに生じます。具体的には、一方のブラウザではログアウトし、もう一方のブラウザではログアウトせずに、一度ブラウザを終了させ、再度同じページを開くと、この問題が発生します²³。FirefoxとChromeを使った具体例で考えてみましょう。ユーザーがFirefoxからログアウトすると、user.forgetメソッドによって記憶ダイジェストがnilになります (リスト8.38)。この時点では、アプリケーションはFirefoxでまだ正常に動作するはずです。つまり、リスト8.39ではlog_outメソッドによってユーザーIDが削除されるため、ハイライトされている2つの条件がfalseになります。