A common usage of I18n with different locales is to create some around
callback in the application controller that sets the locale for the
entire action, via params/url/user/etc., which ensure the locale is
respected for the duration of that action, and resets at the end.
Devise was not respecting the locale when the authenticate failed and
triggered the failure app, because that happens in a warden middleware
right up in the change, by that time the controller around callback had
already reset the locale back to its default, and the failure app would
just translate flash messages using the default locale.
Now we are passing the current locale down to the failure app via warden
options, and wrapping it with an around callback, which makes the
failure app respect the set I18n locale by the controller at the time
the authentication failure is triggered, working as expected. (much more
like a normal controller would.)
I chose to introduce a callback in the failure app so we could wrap the
whole `respond` action processing rather than adding individual `locale`
options to the `I18n.t` calls, because that should ensure other possible
`I18n.t` calls from overridden failure apps would respect the set locale
as well, and makes it more like one would implement in a controller. I
don't recommend people using callbacks in their own failure apps though,
as this is not going to be documented as a "feature" of failures apps,
it's considered "internal" and could be refactored at any point.
It is possible to override the locale with the new `i18n_locale` method,
which simply defaults to the passed locale from the controller.
Closes#5247Closes#5246
Related to: #3052, #4823, and possible others already closed.
Related to warden: (may be closed there afterwards)
https://github.com/wardencommunity/warden/issues/180https://github.com/wardencommunity/warden/issues/170
There was a change introduced in Rails 7.1 that causes all public
actions of non-abstract controllers to become action methods, even if
they happen to match the name of an internal method defined by abstract
`ActionController::Base` and such, which is the case with `_prefixes`.
This change was intentional, it allows for example to have an action
called `status`, which is an internal method, and that is properly
managed as an action method now. However, it broke Devise due to
overriding `_prefixes`, which is a public method of Action Controller.
To fix, we are simply ensuring we keep `_prefixes` as an internal method
rather than action method, which matches previous behavior for this
particular method/implementation in Devise.
Ref: https://github.com/rails/rails/pull/48699
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
