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
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.
This should still keep the devise lookup in the case that a customed scope is not passed as option, but if instead the custom scope is passed, then the find_message method will use it.
This is kind of useful, if i don't want overwrite the devise locale, and use different locale files, but keeping still the fallback of my devise locale.
There's no real need to pass 2 variables to the view to figure that out,
we can simply display the message relying on whether or not the
`@minimum_password_length` variable is present.
I was seeing the following in my console:
```
/home/vagrant/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/devise-3.2.4/app/controllers/devise_controller.rb:9: warning: `*' interpreted as argument prefix
/home/vagrant/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/devise-3.2.4/app/controllers/devise_controller.rb:10: warning: `*' interpreted as argument prefix
```
This change silences this warning.
This updates Devise's StrongParameter support to feature:
- A Null base sanitizer to support existing Rails 3.x installations that
don't want to use StrongParameters yet
- A new, simpler API for ParameterSanitizer: #permit, #permit!, and #forbid
- Overrideable callbacks on a controller-basis, e.g. #create_sessions_params
for passing the current scope's parameters through StrongParameters and
a helper method, whitelisted_params, for rolling your own implementations
of #create_x_params in your own controllers.
- Lots of tests!
This brings support for Rails 4 StrongParameters changes.
- Parameter sanitizing is setup for Devise controllers via
resource_params except Omniauth Callbacks which doesn't use
resource_params.
- Change #build_resource to not call resource_params for get requests.
Parameter sanitizing is only needed when params are posted to the
server so there's no need to try to construct resource params on get
requests (new, edit).
In light of recent discussions around mass assignment security and
the alternate solution of using the controller to filter params, not the model,
a hook/helper is needed to be able to override how the params are filtered
before they are used to build the resource.
