Albeit it's not super recommended, it's possible and even mentioned in
the changelog/wiki in case the app has some additional responder logic
that needs to be applied to Devise across the board.
Just want to have something different than the currently released
version to test out more easily. Plus, this is probably going to become
v4.9.0 final soon anyway.
Unfortunately we can't enforce the version in the gemspec because
responders only supports Rails 5.2 now, and Devise still supports
previous versions.
We'll drop support for those in a future major release, so for now I'm
not adding any version.
This also adds a warning in case someone is using an older version of
responders and tries to set the error/redirect statuses via Devise, so
that they know what to do (upgrade responders) in that case.
This simplifies the logic considerably, as we don't need to reach out to
what seems more internal-ish implementation of Rails with the
interaction between the request and controller objects.
b925880914
Rails implemented a CSRF token storage strategy to allow storing the
CSRF tokens outside of the sessios (for example, in an encrypted
cookie), and changed how the value is kept around during the request
cycle, by using a request.env value.
We still want to ensure the final session value is cleaned correctly in
the test, but the implementation needed to change since we can't simply
delete from the session anymore, we need to make sure we call the Rails
methods for resetting the current storage strategy so it works with all
of them.
https://github.com/rails/rails/pull/44283
Use `AS::Dependencies` as before if we still can, otherwise use the new
direct `constantize` call for Rails 7+.
Leave a TODO to help remind us this can be removed once we drop support
to Rails versions prior to 7 in the future.
Changes deprecated `ActiveSupport::Dependencies.constantize(model_name)` to `model_name.constantize`
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
Remove `ActiveSupport::Dependencies.reference`
This was deleted from Rails: 14d4edd7c3
As far as I can tell, it was meant to add a performance boost at some point in the past but doesn't seem to do anything useful these days.
Update a couple other modules that still referred to `devise_for` to
point to `devise`, and make all of them more consistent. We can only
mention `devise`, that should be clear enough about it being options
for the model method.
Resetting failed attempts after sign in happened inside a warden hook
specific for the lockable module, but that was hidden inside the hook
implementation and didn't allow any user customization.
One such customization needed for example is to direct these updates to
a write DB when using a multi-DB setup. With the logic hidden in the
warden hook this wasn't possible, now that it's exposed in a model
method much like trackable, we can override the model method to wrap it
in a connection switch block for example, point to a write DB, and
simply call `super`.
Closes#5310
Related to #5264 and #5133
Seven year ago rails `session.keys` could be empty if the session was
not loaded yet.
To prevent an error the removed code was introduced
https://github.com/heartcombo/devise/issues/2660
Since then rails changed the behaviour and makes sure that the session
is loaded before someone wants to access any session keys
3498aacbbe
Which means the `session.empty?` is not needed anymore once Rails 5.2+
and upwards only supported.
Deprecate `BLACKLIST_FOR_SERIALIZATION` constant in favor of a more
descriptive name `UNSAFE_ATTRIBUTES_FOR_SERIALIZATION`, removing
unnecessary usage of the word `blacklist` from devise.
The previous constant still works but will emit a warning if used, to
allow anyone still depending on it to upgrade.
This includes an internal backport of the Rails `deprecate_constant`
implementation that exists on Rails 5.1+ to be able to deprecate it
properly in prior versions, while we support those. (which I intend to
drop soon.)
I ran into an issue where options[:except] is a frozen array, which
explodes when we try to concat values in `serializable_hash`. To fix this
we dup the `:except` option before concatenating with the other options
there.
Closes#5278.
This one has been showing up when running tests:
Deprecation warning: Expected string default value for '--orm'; got false (boolean).
This will be rejected in the future unless you explicitly pass the options
`check_default_type: false` or call `allow_incompatible_default_type!` in your code
You can silence deprecations warning by setting the environment variable THOR_SILENCE_DEPRECATION.
* `changed?` behaviour has been updated
Due to 16ae3db5a5 `changed?` has been updated to check for dirtiness after save. The new method that behaves like the old `changed` is `saved_changes?`.
* Add comment to explain which method to used based on which rails version it is
