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`.
After merging https://github.com/plataformatec/devise/pull/4797, I
noticed that we had no specs for the scenarios where this method was
adding the errors to the resource. This commit adds tests to cover those
cases.
The original text:
> You can add it to your Gemfile with:
Could easily be read as: "Run this command to add it to your Gemfile"
That's what I did at least. I think the change makes it much clearer that you need to really manually add a line of text into the Gemfile.
One of the reasons why this is not fully clear is that it's badly visible on Github whether a command is a console / terminal command or a ruby line of code. Visually they look the same except for the $ sign which is easy to overlook.
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.
