問題タブ [devise-confirmable]

デバイスのメール件名のカスタマイズについて多くの議論を見てきましたが、私が望むものを解決しているようには見えません。現在、確認メールの件名は「Qitch.com アカウントの確認」となっています。この電子メールの件名をカスタマイズし、ユーザーの名前の動的な値を追加して、ユーザーALEXがアカウントにサインアップした場合、件名が「Welcome ALEX, confirm your Qitch.com account」の電子メール アドレスを取得するようにしたいと考えています。どうすれば工夫でこれを達成できますか?

devise.en.yml

最後に、返信アドレスまたは差出人アドレスに名前を追加するにはどうすればよいですか。現在、メールを受信すると、送信者:no-reply@qitch.comカスタマイズできる方法はありますかQitch

ありがとう

1. users#registration の下のログイン ユーザー変更メール
2. ユーザーは、この電子メールの変更を確認する電子メールを受け取ります

ステップ 2 で送信される電子メールは、ユーザーが初めて登録し、初めて電子メールを確認する必要がある場合とまったく同じです。

別の電子メール ビューを使用する方法はありますか?デフォルトのメッセージを使用する代わりに、「電子メールの変更を要求しました。リンクの下をクリックしてください..」などのテキストをさらにカスタマイズできます。

これは表面的なものですが、私たちのアプリケーションで切望されていた機能です。

とにかくこれを行うには？敬具！

Devise メールの変更を別のフォームに移動することは可能でしょうか? この機能を users#registrations ページから別のビューに抽出したいと思います。

devise wiki を掘り下げましたが、参照が見つかりませんでした。

確認済みのユーザーが確認を再送信しようとしたときにエラー メッセージを表示したいと考えています。これはdeviseによってすでに提供されているものですか、それともメソッドのいくつかをオーバーライドする必要がありますか? もしそうなら、どの方法ですか？

Edit: thanks @vinodadhikary -- upon further investigation it seems that the error happens when a) the email is not unique, b) the name is not unique or c) the email is obviously fake (h@h.com). If Devise isn't going to accept a signup I would prefer the errors to happen gracefully. The error handling is correct if passwords don't match or a field isn't complete. Also, non-unique names shouldn't be a problem? Is this caused by the creation of slugs (using name as the slug) with FriendlyID?

Original: I'm getting a strange error on my Devise signup when someone signs up when one of the conditions above is met for a signup. I don't think I've done anything outside the realm of normalcy for a Devise installation (used Rails Composer, if it matters). Thanks in advance for any help...

Here is the error:

工夫/登録/new.html.haml:

ユーザー.rb:

完全なスタック トレース:

私たちが達成したいことが可能かどうかはわかりませんが、アドバイスは大歓迎です。

認証にdevise 2.0.4を使用。すべて良い。ユーザーがメールアドレスやパスワードを変更できる設定ビューがあります。

彼らがメールアドレスを変更した場合、デバイス上で :confirmable があるため、新しいアドレスへのメールを確認するまでメールアドレスは変更されません。

私たちの問題は、新しい電子メールアドレスの確認が未解決の場合、パスワードなどの何かを変更しても、電子メールを確認する必要があるというフラッシュメッセージがユーザーに表示されることです。(devise.en.yml のキー: update_needs_confirmation)。私のクライアントはこれを望んでいません。彼らが望んでいるのは、メールアドレスを変更したばかりの場合にのみ、:update_needs_confirmation メッセージが表示されるようにすることです。メールがまだ確認されていない場合でも、他の変更の後ではありません。

これは何らかの形で可能ですか？Devise の登録コントローラー #update メソッド、特にこのセクションのコードと関係があると思います。

電子メールが変更されるたびにこのフラッシュメッセージを1回だけ表示できるかどうか、またその方法を知っている人はいますか? 他の理由で既に行っているため、コントローラーをオーバーライドできてうれしいです。(わかってる、悪い)

情報をありがとう！

メールアドレス（ユーザー名ではありません）でサインインするRailsアプリがあります。なんらかの理由で、パスワードを忘れたアクションで もタイムスタンプも更新されないためreset_password_token、reset_password_sent_atユーザーがリセットしようとすると、「パスワードのリセット トークンの有効期限が切れています。新しいトークンをリクエストしてください」というエラーが発生します。

ある時点で、DB レコードにそれらのフィールドの古いデータがあったため、これは機能しました。これらのフィールドをクリアし、リンクを再試行しましたが、両方ともまだ null です。

特に、途中で何かを変更する前にこれが機能したため、passwords_controllerをオーバーライドする必要はないと思います。リセット フィールドが更新されないのはなぜですか?

**編集** ユーザーが電子メールまたはユーザー名を介してログインできるようにしていますが、これは何か関係がある可能性があります。また、ルート ファイルで、いくつかのデバイス メソッドのオーバーライド コントローラーをセットアップしました。

これらは、devise.rb 初期化ファイルの関連部分です。

終わり

Rails 3.0 アプリで Devise を使用していますが、現在、確認可能および回復可能がオンになっています。これらのモジュールは、ユーザーが自分の電子メール アカウントを確認する必要があり (確認可能)、ユーザーが自分の電子メール アカウントに電子メールを送信してパスワードをリセットできるようにします (回復可能)。

残念ながら、ユーザーが自分のアカウントを確認せずにサイトを使用できるようにする合理的なセキュリティ ポリシーを "考案" (しゃれを意図したもの) するのは困難でした。セキュリティのために次の要件を適用します。

1. アカウントを確認するには、サインインまたはサインインする必要があります。これが当てはまらず、ユーザー A が悪意のあるユーザー B の間違った電子メール アドレスを誤って入力した場合、B は確認用の電子メール リンクを受け取り、自動的にサインインし、そこからパスワードをリセットできます。 「パスワードリセットリンクのメール」経由。A の資格情報でサインインするよう B に要求すると、この可能性がなくなります。

2. メールでパスワードをリセットするには、確認済みのメールが必要です。これは、ユーザー A が悪意のあるユーザー B に属する間違ったメール アドレスを誤って入力した場合、B は確認メール リンクを受け取り、A がアカウントにサインアップしたことを知るためです。したがって、B はサイトにアクセスし、パスワードのリセット機能を使用してアカウントのパスワードを変更し、その後自分のアカウントを確認できます。確認済みの電子メール アドレスを要求すると、この可能性がなくなります。

だから、すべてが順調です。ユーザー A がアカウントを作成し、まだアカウントを確認せず、サイトに戻ってパスワードを忘れた場合を除きます。ここで、A は依存関係の循環ループに陥っています。パスワードをリセットするにはアカウントを確認する必要がありますが、アカウントを確認するには忘れたパスワードでサインインする必要があります。

考えられる解決策は次の 2 つです。

1. サインイン直後にアカウントを確認するようにユーザーに要求します。これにより、サインアップの手間が増えますが、循環依存は解消されます。

2. ユーザーがアカウントを確認せずにパスワードをリセットすることを許可しますが、ユーザーがアカウントを確認する前に機密情報を入力したり、重要なアクションを実行したりすることは許可しません。このように、悪意のあるユーザー B によるアカウントのハイジャックは引き続き可能ですが、貴重な情報や権限なしでアカウントを制御できます。

より良い解決策はありますか？企業はこの問題にどのように対処していますか？すぐにメールで確認する必要のないサイトをいくつか使ってきたので、#2 のような複雑な実装を必要としない方法でこれを行うことができればいいと思います。

ありがとうございました！