As reported in #4981, the method `#increment_failed_attempts` of `Devise::Models::Lockable` was
not concurrency safe. The increment operation was being done in two steps: first the value was read from the database, and then incremented by 1. This may result in wrong values if two requests try to update the value concurrently. For example:
```
Browser1 -------> Read `failed_attempts` from DB (1) -------> Increment `failed_attempts` to 2
Browser2 -------> Read `failed_attempts` from DB (1) -------> Increment `failed_attempts` to 2
```
In the example above, `failed_attempts` should have been set to 3, but it will be set to 2.
This commit handles this case by calling `ActiveRecord::CounterCache.increment_counter` method, which will do both steps at once, reading the value straight from the database.
This commit also adds a `ActiveRecord::AttributeMethods::Dirty#reload` call to ensure that the application gets the updated value - i.e. that other request might have updated.
Although this does not ensure that the value is in fact the most recent one - other request could've updated it after the `reload` call - it seems good enough for this implementation.
Even if a request does not locks the account because it has a stale value, the next one - that updated that value - will do it. That's why we decided not to use a pessimistic lock here.
Closes#4981.
If `Confirmable#confirmation_sent_at` is equal to `0.days.ago`, then
`confirmation_period_valid?` will be deemed valid even if the setting is
configured to disable this outright. To prevent this error, we explicitly
check the configuration setting to be `0.days.ago`.
If called with a hash that has a `default` / `default_proc`
configured, `Devise::ParameterFilter` can add in missing keys
it was due to attempt to sanitise the values for.
This patch prevents this from happening, whilst also clarifying
the filtering intent of `ParamaterFilter`.
(This can also occur if NilClass has been augmented with definitions
for `strip` or `downcase`.)
Fixes#3431.
With this fix, we will try latest changes in Rails 5.2 together with standard auto-generated secret_key_base in development as a fallback.
If no specified key found, auto-generated value will be used instead.
In order to use the `sign_in` helper along with the timeoutable module,
we have to set `env["devise.skip_timeout"] = true` in the request.
Currently, we do this in the sessions controller: https://github.com/plataformatec/devise/blob/master/app/controllers/devise/sessions_controller.rb#L7
This commit adds a note to the `sign_in` documentation to help other
developers that want to use custom warden strategies.
Closes#4773
This permits users to easily customize where the ip address
should be resolved. When fronting the application with a webserver or
load balancer, the ip address may be the server and not be the user.
E.g. consider the IP address is passed as the header: "X-Forwarded-For".
```ruby
class User
devise :trackable
protected
def extract_ip_from(request)
request.headers["X-Forwarded-For"]
end
end
```
- DRY up some of the sample code by refactoring into smaller methods.
- ‘Namespace’ method names to reduce chances of conflict.
- Mark send_pending_devise_notifications, pending_devise_notifications, and render_and_send_devise_message as `private` since they are only used internally.
- Update comments.
When supporting Rails 5.2 credentials on
https://github.com/plataformatec/devise/pull/4712, we ended up breaking
apps that were upgraded to Rails 5.2 and weren't using `credentials`
to store their `secret_key_base`. See
https://github.com/plataformatec/devise/issues/4807 for more context.
To fix it, we're now checking whether the key is present before using it.
Since there weren't any automated test for this - the conditionals were
in a Rails engine initializer - I've extracted it to a new class so that
we are able to test it easily.
Fixes#4807
Creating a new section called `Controller configuration`.
An optional devise configuration is set `config.parent_controller` but this configuration is missing in the `devise.rb` template file.
In Rails 4, for unauthenticated controller tests which trigger the
failure app, ensure that the simulated failure response includes a
content_type (broken in bb44d42).
This works in Rails5, which parses the content-type header on-demand,
but not in Rails4 which requires setting the response's content_type
explicitly.
Fixes#4783.
This fixes#4710.
Rails introduced :secrets in v5.1. They somehow changed it to :credentials. This fix represents this change.
Devise will now look :credentials first, then fallback to :secrets for 5.1.x compatibility then it will check for standard secret key. If three not found then exception will arise.
Addresses #4599
The docs previously mentioned that authentication hooks are not run when `signed_in?` is called, when in fact they are. This commit fixes the comment and suggests calling `authenticated?` on warden directly as an alternative for when you _don't_ want to run auth hooks.
