2012-01-27 8 views
0

Rails 3.1のhas_secure_password機能を使用するようにアプリケーションで認証をアップグレードしました。このプロセスでは、ユーザーがパスワードを変更できるようにするためのページを作成しました。私はそれをテストし、開発環境と本番環境の両方の開発マシンで動作します。Rails 3.2のhas_secure_passwordがHerokuにデプロイされたときに自動的に失敗する

アプリケーションをHerokuにデプロイしたときに試してみたところ、ログアウトして再度ログインしたときを除き、パスワードは変更されませんでした。コンソールで手動でパスワードを変更しようとしましたが、うまくいきます。パスワードと確認のために別のテキストを入力しようとすると、それが想定されている検証が表示されます。つまり、パスワードがアプリに正しく送信されています。ここで

は私のコントローラに関連する変更です:https://github.com/mjm/sis-lunch/commit/930ced467a0e23ad48f4497999183112c5f846b1#diff-2

は、私が欠けているものはありますか?これを静かに失敗させる可能性のあるHerokuのプロダクションでは、何が間違っているのでしょうか?

答えて

0

私はそれを理解したと信じています。私はHerokuにアプリを配備し、移行を実行しました。このアプリは新しいpassword_digest列を完全に認識していませんでしたが、新しいコンソールがあったので、うまく機能しました。 heroku restartを使用してアプリを再起動してください。

0

PeopleControllerTestは空ですが、パスワードフィールドは一括割り当てから保護されているため、開発マシンでどのようにテストしているのか分かりません。それは PeopleControllerで書かれている方法で動作しません。 (これはいいことです)

コントローラーに「Person#password =」と明示的に電話する必要があります。

関連するRailsのソースコードActiveModel::SecurePasswordは、has_secure_passwordを使用したときの動作を正確に示すことができます。

+0

あなたは本当ですか?このコードではパスワードではなくpassword_digestを保護するだけで、プロダクションコンソールにログインして属性=を介してこれらのプロパティを割り当てることができました。 –

+0

ああ、あなたが正しいです。以前私のメモを比較したとき、私はattr_accessibleを見落としました。ドローイングボードに戻って... – fixlr

+0

実際に私自身の質問に答えると、移行を実行した後にアプリを再起動しなければならなかったことが判明しました。 –

関連する問題