Ruby on Rails 12章パスワード再設定(2)

Ruby on Rails 12章パスワード再設定(2)をやりました。

●パスワード再設定のテスト
rails generate integration_test password_resets

一部足している。

test “password resets” do
#テスト範囲
#基本的には、「手作業」でテスト、確認するであろう観点を全部やる。
#・ログインフォームにforgetのリンクがある?
get login_path
assert_select “a[href=?]”, new_password_reset_path
#・再設定の受付フォームが表示されて、
get new_password_reset_path
assert_template ‘password_resets/new’
assert_select “input#password_reset_email”

# POSTする(異常)
post password_resets_path, params:{
password_reset: {
email: “”
}
}
assert_not flash.empty?
assert_template “password_resets/new”

# POSTする(正常)
post password_resets_path, params:{
password_reset: {
email: @user.email
}
}
assert_not_equal @user.reset_digest, @user.reload.reset_digest #ここでPOST済のためダイジェスト発行

#・メールがくる?
assert_equal 1, ActionMailer::Base.deliveries.size
assert_not flash.empty?
assert_redirected_to root_url

#・メールのリンクを踏んで、再設定フォームが見える?
#——————————–
#メールアドレスが無効
user = assigns(:user)
get edit_password_reset_path(user.reset_token, email: “”)
assert_redirected_to root_url

#メールアドレスOK:ユーザが無効
user.toggle!(:activated)
get edit_password_reset_path(user.reset_token, email: user.email)
assert_redirected_to root_url
user.toggle!(:activated) #戻し

#メールアドレスOK:ユーザも有効、トークンが無効
#誰かの乗っ取り懸念
get edit_password_reset_path(‘wrong’, email: user.email)
assert_redirected_to root_url

#全部OK
get edit_password_reset_path(user.reset_token, email: user.email)
assert_template ‘password_resets/edit’
assert_select “input[name=email][type=hidden][value=?]”, user.email

#・再設定を実行できる?
# パスワード2回が不一致
patch password_reset_path(user.reset_token),
params: {
email: user.email,
user:{
password: “foobar”, password_confirmation: “foobaz”
}
}
assert_select ‘div#error_explanation’

# パスワードが空
patch password_reset_path(user.reset_token),
params: {
email: user.email,
user:{
password: “”, password_confirmation: “”
}
}
assert_select ‘div#error_explanation’

patch password_reset_path(user.reset_token),
params:{
email: user.email,
user:{
password: “hogehoge”, password_confirmation: “hogehoge”
}
}
assert is_logged_in?
assert_not flash.empty?
assert_redirected_to user

log_out_as

#古いpwでログインできず,新パスワードでログイン
get login_path
post login_path, params:{
session:{
email: @user.email , password: ‘foobar’
}
}
assert_select ‘div.alert-danger’

get login_path
post login_path, params:{
session:{
email: @user.email , password: ‘hogehoge’
}
}

end

●課題の中で
2時間以内であれば同じURL(トークン)で何度でも再設定できる
というのをつぶしにいく。
ついでに、パスワードの再設定をcontroller実装にしているので、
モデルに寄せに行ったほうがいいような気がする。

ストロングパラメータって、対象モデルを更新する機能の数が多ければ多いほど、
ストロングパラメータの設定が漏れやすくなるので、
モデルの中で集中管理してあったほうがいいんじゃないか?
→渡すほう(コントローラ側)はビューからもらったものを無邪気に渡す。

例えば↓こんな風に更新機能が2つ以上ある場合
・ユーザ情報を更新する画面
・REST APIとして更新API
→どちらもストロングしないといけなくなるはず。

コメントを残す

メールアドレスが公開されることはありません。