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.
Explain a bit more about how `data-confirm` and `data-method` need to be
updated to the turbo versions `data-turbo-confirm` and
`data-turbo-method`, respectively. (and depending on its usage.)
[ci skip]
There's some additional information in the wiki upgrade guide for those
interested, but most of it is covered in the changelog and should
suffice.
The post install message should help guide people upgrading to make sure
they know what to do in this new version, since some may be using Turbo
out there with custom responders and failure apps and those would have
to be removed in order to use these new changes fully. Hopefully that's
enough of a nudge for them.
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 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.
Rails master on Ruby 2.7/3.0 is failing with the following error:
Resolving dependencies...
Could not find compatible versions
Because every version of rails depends on RubyGems >= 3.3.13
and Gemfile-rails-main depends on rails >= 0,
RubyGems >= 3.3.13 is required.
So, because current RubyGems version is = 3.1.6,
version solving has failed.
Trying to run with the latest available rubygems to see if that can fix
the problem, but sticking to the "default" rubygems version on older
Ruby versions to avoid build issues there.
It appears we're getting a newer version of this multipart-post
dependency, which doesn't work well with Ruby 2.2 by using
`Object.deprecate_constant`, resulting in the following error:
.../multipart-post-2.2.0/lib/multipart/post/parts.rb:152:in `<top (required)>':
undefined method `deprecate_constant' for Object:Class (NoMethodError)
Hopefully by locking on a previous version we can just get the build
back to green for now.
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
* Rails and Ruby versions follow the most recent to oldest, except for
Rails main, so we can keep the Gemfile the first one.
* Excluding specific matrix combinations based on the Gemfile first,
Ruby version next, and keep the same order (most recent -> oldest)
* Quote all Ruby versions to keep things consistent. It's required for
the '3.0' version to avoid the float issue where it'd use the latest
3.x instead.
When you copy the commands that have the terminal beginning of line symbol in front of them you now no longer need to first delete this before running the command
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.
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.
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.
