This solves the issue where a package might do:
```
user = User.new
user.email = 'test@test.com'
token = user.generate_reset_token
user.save
send_reset_email(token)
```
Since the save clears the reset token, the user will receive a stale token that no longer works.
Closes#3774
The current implementation is opinionated about the resource should have
an "email" column on it if it is to be recoverable, which isn't
necessarily the case. For example, developers may decide to pull emails
out into their own model or have some other way of communicating
password resets to their users (e.g. text message)
I'm not sure there's an easy test to put together for this case, as
minitest doesn't make it very easy to stub the "email_changed?" to raise
an error. Happy to look into building another model in the
"test/rails_app" if you want to have this properly tested though? Or for
a nice way to get calls to "email_changed?" to raise; minitest isn't
a test framework I'm overly familiar with :).
As a side note, it would be nice if the Validatable module also took
this into account, I may raise another PR for that.
This comes off the back of comments on this commit:
e641b4b7b9
* Replace "the instance variable name in controller" with "the helper methods
names in controller".
Devise dose not define instance variable for controllers but define helper
methods for controllers.
* Replace "the name in routes" with "the scope name in routes".
`singular` is used as an argument of `devise_scope`.
* Add sample codes of routing and controller.
If a new user is created with a reset password token, the previous behavior
would automatically clear the token even when it was desired for setting
the password for the first time.
Our Simple Form generator shouldn't be responsible for generating the `mailer`
view directory, so we should skip it and let the Erb generator do the job.
Closes#3254.
The existing comment seems to be either outdated or obscure. I interpret it as meaning that configure_warden! is invoked by an 'initializer' block in class Devise::Engine, i.e. in lib/devise/rails.rb. However, as far as I can tell the only time the method is invoked is when ActionDispatch::Routing::RouteSet#finalize! is called, and this is aliased by devise to finalize_with_devise!.
Allow basic authentication to be case insensitive as per the HTTP 1.1 spec RFC 2068 Section 11
> It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
We have a particular client in production that has basic auth hard-coded as `basic` rather than `Basic` and devise is rejecting perfectly fine credentials. Making this small change has allowed us to authenticate this client with no issues.
