This changes the OmniAuth "sign in" links to use buttons, which can be
wrapped in an actual HTML form with a method POST, making them work
better with and without Turbo in the app. It doesn't require rails/ujs
anymore in case of a non-Turbo app, as it previously did with links +
method=POST.
Turbo is disabled for those OmniAuth buttons, as they simply don't work
trying to follow the redirect to the OmniAuth provider via fetch,
causing CORS issues/errors.
The deprecation of `devise_error_messages!` wasn't super clear on what
was happening and how to get rid of the message, not it has a more
detailed explanation with an example of what to look for and what to
replace it with.
Closes#5257.
Use `autocomplete="new-password"` or `autocomplete="current-password"` to better signal to browsers and password managers how to handle the password fields.
This feature is especially useful for “change your password” and “new user” forms
Rails 5.1 has deprecated render :text, and HEAD requests on the
omniauth callbacks passthru method is causing errors because the render
:text is non-existant, and there's no template to fall back to.
Replacing :text with :plain, adds a content-type type of text/plain and
also returns the previous message.
render :plain was supported back in rails 4.1.0
http://api.rubyonrails.org/v4.1.0/classes/ActionView/Helpers/RenderingHelper.html#method-i-render
Otherwise we'd be mistakenly displaying the original email in the
message (which is the same we're sending the message to).
Also tweak the messaging a bit in this case, to show that the email "is
being changed" (the change hasn't taken effect yet).
Related to #4455.
This better indicates what the setting is for, and when it's supposed to
be triggered.
We might eventually deprecate the existing password_change on in favor
of password_changed.
This adds a new setting `send_email_change_notification` which will
send an email to the original user email when their email is updated to
a new one.
It doesn't take into account the reconfirmable setting yet, it will be
added next, so that if confirmable is included and reconfirmable is
being used, the email will be triggered when the email change is
requested, not when confirmed (e.g when we store the email in
`unconfirmed_email`, not when it's later copied to `email` when that is
confirmed).
The sign_in method permits the bypass option
that ignore the others options used. This behavior
has lead some users to a misconfusion what the
method really does.
This change deprecate the bypass option in favor
of a method that only does the sign in with bypass.
Closes#3981
Rails 5 will [not have `hide_action` any longer](https://github.com/rails/rails/pull/18371/files), as the Rails convention is to not expose private or protected methods as actions, thus obviating the need for `hide_action`.
Presumably, there is code inheriting from `DeviseController` that is
calling these helpers, so they cannot be private, so protected seems to
be the only way to get Devise working with Rails 5.
