"Invalid Email or password." is grammatically incorrect, a change
introduced a while ago by #4014.
Signed-off-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
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
It appears some people use the recall functionality with a redirect
response, and Devise starting on version 4.9 was overriding that status
code to the configured `error_status` for better Turbo support, which
broke the redirect functionality / expectation.
While I don't think it's really great usage of the recall functionality,
or at least it was unexpected usage, it's been working like that
basically forever where recalling would use the status code of the
recalled action, so this at least keeps it more consistent with that
behavior by respecting redirects and keeping that response as a redirect
based on the configured status, which should also work with Turbo I
believe, and makes this less of a breaking change.
Closes#5570Closes#5561 (it was closed previously, but related / closes with an
actual change now.)
While introducing this on turbo, looks like no specific test was added,
so this at least covers that a bit.
It needs some conditional checks since not all supported Rails +
Responders version work with the customization, so there's one test for
the hardcoded status version too, which can be removed in the future.
It appears setting the `rack.session` to a simple hash doesn't work
anymore as it now has a few additional methods Rails is relying on to
determine whether it's enabled or not:
https://github.com/rails/rails/pull/42231
Failure:
NoMethodError: undefined method `enabled?' for {}:Hash
rails (f55cdafe4b82) actionpack/lib/action_dispatch/middleware/flash.rb:62:in `commit_flash'
Turns we we don't seem to need to set `rack.session` for the tests here.
This allows us to remove the dependency on the XML serializer provided
by the external `activemodel-serializers-xml` gem, and eliminates the
following deprecation warning:
DEPRECATION WARNING: ActiveModel::Errors#to_xml is deprecated and
will be removed in Rails 6.2.
Please note: this does not mean Devise doesn't support XML, it simply
means our test suite will use JSON to test non-navigatable formats
instead of XML, for simplicity. Devise's job is not to test object
serialization, so as long as your objects properly serialize to
XML/JSON/any other format, it should work out of the box.
* Add Devise::FailureApp#{relative_url_root, relative_url_root?}
Also support missing action_controller.relative_url_root configuration.
* Dry assignment of relative_url_root
Also this commit adds support for
Rails.application.config.action_controller.relative_url_root
Devise.available_router_name currently returns either
Devise.router_name or :main_app. As such, any redirecting is done
within either of those contexts. Which leads to undesirable redirects
for scopes that reside in an isolate_namespace mounted engine.
This commit makes it possible for FailureApp’s redirect behavior to be
performed in the context of the router_name given to devise_for.
Test case added to cover undesirable behavior. Without change to
lib/devise/failure_app.rb, test case throws exception.
