18/02/2020 Railsチュートリアル Ruby on Rails 学習メモ

らくだ🐫にもできるRailsチュートリアル｜10.2

10.2 認可

ウェブアプリケーションの文脈では、認証 (authentication) はサイトのユーザーを識別することであり、認可 (authorization) はそのユーザーが実行可能な操作を管理することです。

現状ではログインしていないユーザーでもどのユーザー情報でも編集できてしまうため
ユーザーにログインを要求し、自分以外のユーザー情報を変更できないように制御する
→セキュリティ上の制御機構をセキュリティモデルと呼ぶ

やっていくこと

ログインしていないユーザーが保護されたページにアクセスしようとした場合ログインページに転送してメッセージを表示させる
さらに、許可されていないページにアクセス済のユーザーがいたらルートURLにリダイレクトさせる

10.2.1 ユーザーにログインを要求する

Usersコントローラの中でbeforeフィルターを使ってユーザーにログインを要求する

beforeフィルターとはなんぞ

before_actionメソッドを使って何らかの処理が実行される直前に特定のメソッドを実行する仕組みです

class UsersController < ApplicationController
  # 直前にlogged_in_userメソッドを実行　edit,updateアクションにのみ適用
  before_action :logged_in_user, only: [:edit, :update]
・
・
・
  # 外部に公開されないメソッド
  private

    def user_params
      params.require(:user).permit(:name, :email, :password,
                                   :password_confirmation)
    end
    
    # beforeアクション

    # ログイン済みユーザーかどうか確認
    def logged_in_user
      # logged_in?メソッドがfalseの場合
      unless logged_in?
        # flashｓでエラーメッセージを表示
        flash[:danger] = "Please log in."
        # login_urlにリダイレクト
        redirect_to login_url
      end
    end
end

class UsersController < ApplicationController

# 直前にlogged_in_userメソッドを実行　edit,updateアクションにのみ適用

before_action :logged_in_user, only: [:edit, :update]

・

# 外部に公開されないメソッド

private

def user_params

params.require(:user).permit(:name, :email, :password,

:password_confirmation)

end

# beforeアクション

# ログイン済みユーザーかどうか確認

def logged_in_user

# logged_in?メソッドがfalseの場合

unless logged_in?

# flashｓでエラーメッセージを表示

flash[:danger] = "Please log in."

# login_urlにリダイレクト

redirect_to login_url

end

unless文

if文が条件式の評価がtrueの場合に処理を実行するのに対して
unless文は条件式の評価がfalseの場合に処理を実行する
上記の場合
ヘルパーに定義したlogged_in?メソッドがfalse（current_userがnil）の場合に処理（エラーメッセージの表示→login_urlにリダイレクト）が行われる
↓SessionsHelperに定義されているlogged_in?メソッドとlogged_in?メソッドで呼んでるcurrent_userメソッドはこちら

module SessionsHelper
・
・
・
  # 記憶トークン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
・
・
・

module SessionsHelper

・

# 記憶トークン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

# ユーザーがログインしていればtrue、その他ならfalseを返す

def logged_in?

!current_user.nil?

end

・

現状のテストはRED

原因は、editアクションやupdateアクションでログインを要求するようになったため、ログインしていないユーザーだとこれらのテストが失敗するようになったためです。

→editアクションやupdateアクションをテストする前にログインしておく必要がある！
→log_in_asヘルパー (test_helper.rbに定義) を使う

・
・
・
  test "unsuccessful edit" do
    # test userとしてログイン
    log_in_as(@user)
    # edit_user_path(@user)にgetのリクエスト
    get edit_user_path(@user)
・
・
・
  test "successful edit" do
    # test userとしてログイン
    log_in_as(@user)
    # edit_user_path(@user)にgetのリクエスト
・
・
・

・

test "unsuccessful edit" do

# test userとしてログイン

log_in_as(@user)

# edit_user_path(@user)にgetのリクエスト

get edit_user_path(@user)

・

test "successful edit" do

# test userとしてログイン

log_in_as(@user)

# edit_user_path(@user)にgetのリクエスト

・

(リスト 10.17のsetupメソッド内でログイン処理をまとめてしまうことも可能です。しかし、10.2.3で片方のテストをログインする前に編集ページにアクセスするように変更したいので、ここでまとめてしまっても結局は元に戻すことになってしまいます。)

セキュリティモデルに関するテスト

現状ではセキュリティモデルに関する実装を取り外しても（beforeフィルターをコメントアウト）テストが greenになってしまう！
これでは危険が危ないので検知できるようにテストを修正してく
→beforeフィルターは基本的にアクションごとに適用していく。よってUsersコントローラのテストもアクションごとに書いていく。

正しい種類のHTTPリクエストでeditアクション（getのリクエスト）とupdateアクション（patchのリクエスト）をそれぞれ実行
flashにメッセージが代入されたか
ログイン画面にリダイレクトされたか

require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest
・
・
・
  test "should get new" do
    get signup_path
    assert_response :success
  end
  
  test "should redirect edit when not logged in" do
    # edit_user_path(@user)にgetのリクエスト
    get edit_user_path(@user)
    # flashがemptyではない（flashが表示されている→エラー表示）
    assert_not flash.empty?
    # login_urlにリダイレクトされる
    assert_redirected_to login_url
  end

  test "should redirect update when not logged in" do
    # paramsハッシュに以下のデータを持たせてuser_path(@user)にpatchのリクエスト
    patch user_path(@user), params: { user: { name: @user.name,
                                              email: @user.email } }
    # flashがemptyではない（flashが表示されている→エラー表示）
    assert_not flash.empty?
    # login_urlにリダイレクトされる
    assert_redirected_to login_url
  end

end

require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest

・

test "should get new" do

get signup_path

assert_response :success

end

test "should redirect edit when not logged in" do

# edit_user_path(@user)にgetのリクエスト

get edit_user_path(@user)

# flashがemptyではない（flashが表示されている→エラー表示）

assert_not flash.empty?

# login_urlにリダイレクトされる

assert_redirected_to login_url

end

test "should redirect update when not logged in" do

# paramsハッシュに以下のデータを持たせてuser_path(@user)にpatchのリクエスト

patch user_path(@user), params: { user: { name: @user.name,

email: @user.email } }

# flashがemptyではない（flashが表示されている→エラー表示）

assert_not flash.empty?

# login_urlにリダイレクトされる

assert_redirected_to login_url

end

テストが意図の通りに作動するか確認

class UsersController < ApplicationController
  #before_action～をコメントアウトするとテストはREDに
  #コメントアウトを外すとテストはGREENになる
  before_action :logged_in_user, only: [:edit, :update]
  .
  .
  .
end

class UsersController < ApplicationController

#before_action～をコメントアウトするとテストはREDに

#コメントアウトを外すとテストはGREENになる

before_action :logged_in_user, only: [:edit, :update]

end

演習

デフォルトのbeforeフィルターは、すべてのアクションに対して制限を加えます。今回のケースだと、ログインページやユーザー登録ページにも制限の範囲が及んでしまうはずです (結果としてテストも失敗するはずです)。リスト 10.15のonly:オプションをコメントアウトしてみて、テストスイートがそのエラーを検知できるかどうか (テストが失敗するかどうか) 確かめてみましょう。

 FAIL["test_invalid_signup_information", UsersSignupTest, 0.8014602010002818]
 test_invalid_signup_information#UsersSignupTest (0.80s)
        expecting <"users/new"> but rendering with <[]>
        test/integration/users_signup_test.rb:13:in `block in <class:UsersSignupTest>'

 FAIL["test_valid_signup_information", UsersSignupTest, 0.8080838440000662]
 test_valid_signup_information#UsersSignupTest (0.81s)
        "User.count" didn't change by 1.
        Expected: 2
          Actual: 1
        test/integration/users_signup_test.rb:21:in `block in <class:UsersSignupTest>'

 FAIL["test_should_get_new", UsersControllerTest, 0.9231980270001259]
 test_should_get_new#UsersControllerTest (0.92s)
        Expected response to be a <2XX: success>, but was a <302: Found> redirect to <http://www.example.com/login>
        Response body: <html><body>You are being <a href="http://www.example.com/login">redirected</a>.</body></html>
        test/controllers/users_controller_test.rb:12:in `block in <class:UsersControllerTest>'

FAIL["test_invalid_signup_information", UsersSignupTest, 0.8014602010002818]

test_invalid_signup_information#UsersSignupTest (0.80s)

expecting <"users/new"> but rendering with <[]>

test/integration/users_signup_test.rb:13:in `block in <class:UsersSignupTest>'

FAIL["test_valid_signup_information", UsersSignupTest, 0.8080838440000662]

test_valid_signup_information#UsersSignupTest (0.81s)

"User.count" didn't change by 1.

Expected: 2

Actual: 1

test/integration/users_signup_test.rb:21:in `block in <class:UsersSignupTest>'

FAIL["test_should_get_new", UsersControllerTest, 0.9231980270001259]

test_should_get_new#UsersControllerTest (0.92s)

Expected response to be a <2XX: success>, but was a <302: Found> redirect to <http://www.example.com/login>

Response body: <html><body>You are being <a href="http://www.example.com/login">redirected</a>.</body></html>

test/controllers/users_controller_test.rb:12:in `block in <class:UsersControllerTest>'

これちょっと悩んで、
本文にはログインページやユーザー登録ページにも制限の範囲が及んでしまうはずってあるんだけど
ユーザー登録ページ関連にはエラーも出てるし実際動作もおかしくなる（ログインページに飛ばされるループになる）けど
ログインページではエラーも異常も出ないんだよね。
本文通りならログインページ関連にもエラーが出ないとおかしいのでは？どこか間違ってるのでは？ってなったんだけど
ログインページ関連はSessionsControllerなのでUsersControllerのbeforeフィルターの制限が及ぶわけないのよね。
と、納得した🐫

10.2.2 正しいユーザーを要求する

ログインを要求するだけではなく、ログインしたユーザーが自分だけの情報を編集できるようにする。
→現状ではログインさえしていれば他ユーザーの情報も更新できてしまう
ログインしているからと言って、他のユーザーの情報まで編集できてしまうのは🙅‍♀️
これをテスト駆動開発でやっていく！

他ユーザーの情報が編集できないかを確認するテスト

テスト用のデータに2人目のユーザーを作る

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

michael:

name: Michael Example

email: michael@example.com

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

archer:

name: Sterling Archer

email: duchess@example.gov

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

log_in_asメソッドを使って、editアクションとupdateアクションをテストする

このとき、既にログイン済みのユーザーを対象としているため、ログインページではなくルートURLにリダイレクトしている点に注意してください。

require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest
  
  # テストユーザーを設定
  def setup
    @user = users(:michael)
    # 追加したユーザーを@other_userに代入
    @other_user = users(:archer)
  end
・
・
・
  test "should redirect edit when logged in as wrong user" do
    # @other_userとしてログインする
    log_in_as(@other_user)
    # @userのユーザー情報編集ページにgetのリクエスト
    get edit_user_path(@user)
    # フラッシュがemptyである
    assert flash.empty?
    # root_urlにリダイレクトされる
    assert_redirected_to root_url
  end

  test "should redirect update when logged in as wrong user" do
    # @other_userとしてログインする
    log_in_as(@other_user)
    # @userのupdateアクションにparamsハッシュのデータを持たせてPATCHのリクエスト　　
    patch user_path(@user), params: { user: { name: @user.name,
                                              email: @user.email } }
    # フラッシュがemptyである
    assert flash.empty?
    # root_urlにリダイレクトされる
    assert_redirected_to root_url
  end

end

require 'test_helper'

class UsersControllerTest < ActionDispatch::IntegrationTest

# テストユーザーを設定

def setup

@user = users(:michael)

# 追加したユーザーを@other_userに代入

@other_user = users(:archer)

end

・

test "should redirect edit when logged in as wrong user" do

# @other_userとしてログインする

log_in_as(@other_user)

# @userのユーザー情報編集ページにgetのリクエスト

get edit_user_path(@user)

# フラッシュがemptyである

assert flash.empty?

# root_urlにリダイレクトされる

assert_redirected_to root_url

end

test "should redirect update when logged in as wrong user" do

# @other_userとしてログインする

log_in_as(@other_user)

# @userのupdateアクションにparamsハッシュのデータを持たせてPATCHのリクエスト　　

patch user_path(@user), params: { user: { name: @user.name,

email: @user.email } }

# フラッシュがemptyである

assert flash.empty?

# root_urlにリダイレクトされる

assert_redirected_to root_url

end

別のユーザーのプロフィールを編集しようとしたらリダイレクトさせる

beforeフィルターで管理
→correct_userというメソッドを作成し、ログインユーザーが別のユーザーのプロフィールを編集しようとしたらリダイレクトさせる

beforeフィルターのcorrect_userで@user変数を定義しているため、リスト 10.25ではeditとupdateの各アクションから、@userへの代入文を削除している点にも注意してください。

class UsersController < ApplicationController
  # 直前にlogged_in_userメソッドを実行　edit,updateアクションにのみ適用
  before_action :logged_in_user, only: [:edit, :update]
  # 直前にcorrect_userメソッドを実行　edit,updateアクションにのみ適用
  before_action :correct_user,   only: [:edit, :update]
・
・
・
  #ユーザーのeditアクション
  def edit
    # 直前に実行されるcorrect_userメソッドで定義されているため下記代入文は削除
    # @user = User.find(params[:id])
  end
  
  def update
    # 直前に実行されるcorrect_userメソッドで定義されているため下記代入文は削除
    # @user = User.find(params[:id])
    #指定された属性の検証がすべて成功した場合@userの更新と保存を続けて同時に行う
    if @user.update_attributes(user_params)
      # 更新成功のフラッシュメッセージ
      flash[:success] = t('.profile_updated')
      # @user（プロフィールページ）へリダイレクト
      redirect_to @user
    else
      render 'edit'
    end
  end
  
  # 外部に公開されないメソッド
  private

    def user_params
      params.require(:user).permit(:name, :email, :password,
                                   :password_confirmation)
    end
    
    # beforeアクション

    # ログイン済みユーザーかどうか確認
    def logged_in_user
      # logged_in?がfalseの場合
      unless logged_in?
        # flashsでエラーメッセージを表示
        flash[:danger] = t('users.please_log_in')
        # login_urlにリダイレクト
        redirect_to login_url
      end
    end
    
    # 正しいユーザーかどうか確認
    def correct_user
      @user = User.find(params[:id])
      # root_urlにリダイレクト　以下の式がfalseの場合　@userとcurrent_userが等しい
      redirect_to(root_url) unless @user == current_user
    end
end

class UsersController < ApplicationController

# 直前にlogged_in_userメソッドを実行　edit,updateアクションにのみ適用

before_action :logged_in_user, only: [:edit, :update]

# 直前にcorrect_userメソッドを実行　edit,updateアクションにのみ適用

before_action :correct_user, only: [:edit, :update]

・

#ユーザーのeditアクション

def edit

# 直前に実行されるcorrect_userメソッドで定義されているため下記代入文は削除

# @user = User.find(params[:id])

end

def update

# 直前に実行されるcorrect_userメソッドで定義されているため下記代入文は削除

# @user = User.find(params[:id])

#指定された属性の検証がすべて成功した場合@userの更新と保存を続けて同時に行う

if @user.update_attributes(user_params)

# 更新成功のフラッシュメッセージ

flash[:success] = t('.profile_updated')

# @user（プロフィールページ）へリダイレクト

redirect_to @user

else

render 'edit'

end

# 外部に公開されないメソッド

private

def user_params

params.require(:user).permit(:name, :email, :password,

:password_confirmation)

end

# beforeアクション

# ログイン済みユーザーかどうか確認

def logged_in_user

# logged_in?がfalseの場合

unless logged_in?

# flashsでエラーメッセージを表示

flash[:danger] = t('users.please_log_in')

# login_urlにリダイレクト

redirect_to login_url

end

# 正しいユーザーかどうか確認

def correct_user

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

# root_urlにリダイレクト　以下の式がfalseの場合　@userとcurrent_userが等しい

redirect_to(root_url) unless @user == current_user

end

リファクタリング

一般的な慣習に倣ってcurrent_user?という論理値を返すメソッドを実装します

unless @user == current_user
#↑これ　が　↓こうなって　コードが少しわかりやすくなるとの事
unless current_user?(@user)

unless @user == current_user

#↑これ　が　↓こうなって　コードが少しわかりやすくなるとの事

unless current_user?(@user)

correct_userの中で使えるようにする為にSessionsヘルパーの中に追加する

module SessionsHelper
  
  # 渡されたユーザーでcookieを使ってログインする
  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
  
  # 渡されたユーザーがログイン済みユーザーであればtrueを返す
  def current_user?(user)
    user == current_user
  end
・
・
・

module SessionsHelper

# 渡されたユーザーでcookieを使ってログインする

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

# 渡されたユーザーがログイン済みユーザーであればtrueを返す

def current_user?(user)

user == current_user

end

・

Usersコントローラーに反映させる

    # beforeアクション

    # ログイン済みユーザーかどうか確認
    def logged_in_user
      # logged_in?がfalseの場合
      unless logged_in?
        # flashsでエラーメッセージを表示
        flash[:danger] = t('users.please_log_in')
        # login_urlにリダイレクト
        redirect_to login_url
      end
    end
    
    # 正しいユーザーかどうか確認
    def correct_user
      @user = User.find(params[:id])
      # root_urlにリダイレクト　current_user?メソッドがfalseの場合
      redirect_to(root_url) unless current_user?(@user)
    end
end

# beforeアクション

# ログイン済みユーザーかどうか確認

def logged_in_user

# logged_in?がfalseの場合

unless logged_in?

# flashsでエラーメッセージを表示

flash[:danger] = t('users.please_log_in')

# login_urlにリダイレクト

redirect_to login_url

end

# 正しいユーザーかどうか確認

def correct_user

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

# root_urlにリダイレクト　current_user?メソッドがfalseの場合

redirect_to(root_url) unless current_user?(@user)

end

演習

何故editアクションとupdateアクションを両方とも保護する必要があるのでしょうか? 考えてみてください。

上記のアクションのうち、どちらがブラウザで簡単にテストできるアクションでしょうか?

他のユーザーのユーザー情報編集ページを表示させない為にeditアクション、データを更新させないためにupdateアクションをそれぞれ保護する必要がある
viewが定義されているeditアクション

10.2.3 フレンドリーフォワーディング

各種リダイレクト先はユーザーが開こうとしていたページに設定するのが親切というもの！

ログインしていないユーザーが編集ページにアクセスしようとしていたなら、ユーザーがログインした後にはその編集ページにリダイレクトされるようにするのが望ましい動作です。

フレンドリーフォワーディングのテスト

ログインのテスト（ログインした後に編集ページへアクセスするという順序）を逆にする

編集ページにアクセス
ログイン
プロフィールページではなく編集ページにリダイレクト

・
・
・
  # successful editのテストを編集していく
  test "successful edit with friendly forwarding" do
    # edit_user_path(@user)にgetのリクエスト
    get edit_user_path(@user)
    # @userとしてログイン
    log_in_as(@user)
    # edit用のテンプレートはリダイレクトで描画されるので下記一文は削除
    # assert_template 'users/edit'
    # @userのユーザー編集ページにリダイレクトされる
    assert_redirected_to edit_user_url(@user)
    # nameに"Foo Bar"を代入
    name  = "Foo Bar"
    # emailに"foo@bar.com"を代入
    email = "foo@bar.com"
    # 有効なparams:を持ったuser_path(@user)でpatch（更新）のリクエスト
    patch user_path(@user), params: { user: { name:  name,
                                              email: email,
                                              password:              "",
                                              password_confirmation: "" } }
    # falseである→　flashが空っぽであるか
    assert_not flash.empty?
    # リダイレクトされている　→@user（プロフィールページ）
    assert_redirected_to @user
    # @user（プロフィールページ）を再読み込み
    @user.reload
    # name（入力値）と@user.name（DBの値）が等しい
    assert_equal name,  @user.name
    # email（入力値）と@user.email（DBの値）が等しい
    assert_equal email, @user.email
  end
end

・

# successful editのテストを編集していく

test "successful edit with friendly forwarding" do

# edit_user_path(@user)にgetのリクエスト

get edit_user_path(@user)

# @userとしてログイン

log_in_as(@user)

# edit用のテンプレートはリダイレクトで描画されるので下記一文は削除

# assert_template 'users/edit'

# @userのユーザー編集ページにリダイレクトされる

assert_redirected_to edit_user_url(@user)

# nameに"Foo Bar"を代入

name = "Foo Bar"

# emailに"foo@bar.com"を代入

email = "foo@bar.com"

# 有効なparams:を持ったuser_path(@user)でpatch（更新）のリクエスト

patch user_path(@user), params: { user: { name: name,

email: email,

password: "",

password_confirmation: "" } }

# falseである→　flashが空っぽであるか

assert_not flash.empty?

# リダイレクトされている　→@user（プロフィールページ）

assert_redirected_to @user

# @user（プロフィールページ）を再読み込み

@user.reload

# name（入力値）と@user.name（DBの値）が等しい

assert_equal name, @user.name

# email（入力値）と@user.email（DBの値）が等しい

assert_equal email, @user.email

end

ん？
successful editのテストを編集するのででいいんだよね？（？

フレンドリーフォワーディングの実装

ユーザーを希望のページに転送するには、リクエスト時点のページをどこかに保存しておき、その場所にリダイレクトさせる必要があります。

Sessionヘルパーにstore_location（リクエスト時点のページを保存）とredirect_back_or（ユーザーを希望のページに転送）の二つのメソッドを定義する

２つのヘルパーメソッドの実装

store_locationとredirect_back_orの2つのメソッドを定義していく

・
・
・
  # 記憶したURL (もしくはデフォルト値) にリダイレクト
  def redirect_back_or(default)
    # リダイレクト（session[:forwarding_url]の値、値がnilデフォルト値へ)
    redirect_to(session[:forwarding_url] || default)
    # session変数の:forwarding_urlキーの値をdelete
    session.delete(:forwarding_url)
  end

  # アクセスしようとしたURLを覚えておく
  def store_location
    # session変数の:forwarding_urlキーに格納 request.original_urlで取得したリクエスト先urlにGETリクエストが送られたときのみ
    session[:forwarding_url] = request.original_url if request.get?
  end
end

・

# 記憶したURL (もしくはデフォルト値) にリダイレクト

def redirect_back_or(default)

# リダイレクト（session[:forwarding_url]の値、値がnilデフォルト値へ)

redirect_to(session[:forwarding_url] || default)

# session変数の:forwarding_urlキーの値をdelete

session.delete(:forwarding_url)

end

# アクセスしようとしたURLを覚えておく

def store_location

# session変数の:forwarding_urlキーに格納 request.original_urlで取得したリクエスト先urlにGETリクエストが送られたときのみ

session[:forwarding_url] = request.original_url if request.get?

end

requestオブジェクト

ブラウザから返されるリクエストに関する情報が多数含まれている

Action Controller の概要 - Railsガイド

https://railsguides.jp/action_controller_overview.html#requestオブジェクト

Ruby on Railsの生産的なプロダクト開発を加速する、1,600ページ以上ある大型リファレンスガイドです。電子書籍や全文検索、法人向けサービスも提供しています。

Action Controller の概要 - Railsガイド

request.original_url　→　現在のリクエストURLをStringとして返す
request.get?　→　HTTPメソッドがGETの時trueを返す

beforeフィルターを修正

store_locationメソッドを使って、早速beforeフィルターのlogged_in_userメソッドを修正

・
・
・
    # beforeアクション

    # ログイン済みユーザーかどうか確認
    def logged_in_user
      # logged_in?がfalseの場合
      unless logged_in?
        # SessionsHelperのstore_locationメソッドを呼び出す
        store_location
        # flashsでエラーメッセージを表示
        flash[:danger] = t('users.please_log_in')
        # login_urlにリダイレクト
        redirect_to login_url
      end
    end
    
    # 正しいユーザーかどうか確認
    def correct_user
      @user = User.find(params[:id])
      # root_urlにリダイレクト　current_user?メソッドがfalseの場合
      redirect_to(root_url) unless current_user?(@user)
    end
end

・

# beforeアクション

# ログイン済みユーザーかどうか確認

def logged_in_user

# logged_in?がfalseの場合

unless logged_in?

# SessionsHelperのstore_locationメソッドを呼び出す

store_location

# flashsでエラーメッセージを表示

flash[:danger] = t('users.please_log_in')

# login_urlにリダイレクト

redirect_to login_url

end

# 正しいユーザーかどうか確認

def correct_user

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

# root_urlにリダイレクト　current_user?メソッドがfalseの場合

redirect_to(root_url) unless current_user?(@user)

end

createアクションを修正

createアクションにredirect_back_orメソッドを組み込んでリダイレクト先を呼び出す

・
・
・
  def create
    @user = User.find_by(email: params[:session][:email].downcase)
    if @user && @user.authenticate(params[:session][:password])
      #session[:user_id] = @user　と言う事
      log_in @user
      #params[:session][:remember_me]が1の時@userを記憶　そうでなければuserを忘れる
      params[:session][:remember_me] == '1' ? remember(@user) : forget(@user)
      #SessionsHelperで定義したredirect_back_orメソッドを呼び出してリダイレクト先を定義
      # 本文ではデフォルト値が「user」になってるけど「@user」が正解
      redirect_back_or @user
    else
      flash.now[:danger] = t('.login_error')
      render 'new'
    end
  end
・
・
・

・

def create

@user = User.find_by(email: params[:session][:email].downcase)

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

#session[:user_id] = @user　と言う事

log_in @user

#params[:session][:remember_me]が1の時@userを記憶　そうでなければuserを忘れる

params[:session][:remember_me] == '1' ? remember(@user) : forget(@user)

#SessionsHelperで定義したredirect_back_orメソッドを呼び出してリダイレクト先を定義

# 本文ではデフォルト値が「user」になってるけど「@user」が正解

redirect_back_or @user

else

flash.now[:danger] = t('.login_error')

render 'new'

end

・

演習

フレンドリーフォワーディングで、渡されたURLに初回のみ転送されていることを、テストを書いて確認してみましょう。次回以降のログインのときには、転送先のURLはデフォルト (プロフィール画面) に戻っている必要があります。ヒント: リスト 10.29のsession[:forwarding_url]が正しい値かどうか確認するテストを追加してみましょう。

7.1.3で紹介したdebuggerメソッドをSessionsコントローラのnewアクションに置いてみましょう。その後、ログアウトして /users/1/edit にアクセスしてみてください (デバッガーが途中で処理を止めるはずです)。ここでコンソールに移り、session[:forwarding_url]の値が正しいかどうか確認してみましょう。また、newアクションにアクセスしたときのrequest.get?の値も確認してみましょう (デバッガーを使っていると、ときどき予期せぬ箇所でターミナルが止まったり、おかしい挙動を見せたりします。熟練の開発者になった気になって (コラム 1.1)、落ち着いて対処してみましょう)。

・
・
・
  test "successful edit with friendly forwarding" do
    # edit_user_path(@user)にgetのリクエスト
    get edit_user_path(@user)
    # session[:forwarding_url]とedit_user_url(@user)が等しい時にtrue
    assert_equal session[:forwarding_url], edit_user_url(@user)
    # @userとしてログイン
    log_in_as(@user)
    # edit用のテンプレートはリダイレクトで描画されるので下記一文は削除
    # assert_template 'users/edit'
    # session[:forwarding_url]がnilの時true
    assert_nil session[:forwarding_url]
    # @userのユーザー編集ページにリダイレクトされる
    assert_redirected_to edit_user_url(@user)
    # nameに"Foo Bar"を代入
    name  = "Foo Bar"
    # emailに"foo@bar.com"を代入
    email = "foo@bar.com"
    # 有効なparams:を持ったuser_path(@user)でpatch（更新）のリクエスト
    patch user_path(@user), params: { user: { name:  name,
                                              email: email,
                                              password:              "",
                                              password_confirmation: "" } }
・
・
・

・

test "successful edit with friendly forwarding" do

# edit_user_path(@user)にgetのリクエスト

get edit_user_path(@user)

# session[:forwarding_url]とedit_user_url(@user)が等しい時にtrue

assert_equal session[:forwarding_url], edit_user_url(@user)

# @userとしてログイン

log_in_as(@user)

# edit用のテンプレートはリダイレクトで描画されるので下記一文は削除

# assert_template 'users/edit'

# session[:forwarding_url]がnilの時true

assert_nil session[:forwarding_url]

# @userのユーザー編集ページにリダイレクトされる

assert_redirected_to edit_user_url(@user)

# nameに"Foo Bar"を代入

name = "Foo Bar"

# emailに"foo@bar.com"を代入

email = "foo@bar.com"

# 有効なparams:を持ったuser_path(@user)でpatch（更新）のリクエスト

patch user_path(@user), params: { user: { name: name,

email: email,

password: "",

password_confirmation: "" } }

・

2.
session[:forwarding_url]の値 → ～/users/1/editとなるはず

(byebug) session[:forwarding_url]
"https:/*******amazonaws.com/users/1/edit"

1 2	(byebug) session[:forwarding_url] "https:/*******amazonaws.com/users/1/edit"

request.get?の値 → trueとなるはず

(byebug) request.get?
true

1 2	(byebug) request.get? true

まとめとか感想

本文にちょこちょこ引っかかりまくって思いのほか時間がかかったりだけど、その分しっかり調べたから！と、思う🐫
フレンドリーフォワーディングたいせつ

らくだ🐫にもできるRailsチュートリアルとは

「ド」が付く素人のらくだ🐫が勉強するRailsチュートリアルの学習記録です。
自分用に記録していますが、お役に立つことがあれば幸いです。

調べたとはいえらくだ🐫なりの解釈や説明が含まれます。間違っている部分もあるかと思います。そんな所は教えて頂けますと幸いなのですが、このブログにはコメント機能がありません💧お手数おかけしますがTwitterなどでご連絡いただければ幸いです