If you want to add a new behavior to your devise
controllers but you don't want to override devise's
default workflow, just pass a block around resource.
This would give you for example, the ability to
trigger background jobs after user signs in.
For #2627
When allow_unconfirmed_access_for > 0, users may
be already signed in at the time they confirm
their account. Consequently, the default
confirmation should be compatible with this
possibility. Additionally, they should not be
redirected to the sign in form after confirmation
in this case. So I've changed
ConfirmationsController#after_confirmation_path_for
to send the user to the root path when signed in,
or the sign in form otherwise.
The :confirmed default message in devise.en.yml
used to say "You are now signed in." This is no
longer the default behavior in v3.1.0.
This commit renames that message to
:confirmed_and_signed_in and changes the :confirmed
message to be appropriate for the default post-
confirmation location (which is now the new session
page). The new :confirmed message reads:
"Your account was successfully confirmed. Please
sign in."
Devise::RegistrationsController#create set self.resource to the return value of build_resource--which is nil, because build_resource sets self.resource to an actual resource object. This caused attempting to save the resource (two lines down) to fail with "undefined method `save' on nil:NilClass."
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).
It is advisable to use link_to for mostly GET operations. Actions like DESTROY when presented as a link can cause severe vulnerabilities.
Hence using a button is advisable.
