Previously checks whether a certain scope is signed in were performed using warden’s
`authenticate?` or `authenticate` methods which would run the strategies and sign in the
scope if valid params were given. We want to remove this side effect from query methods.
References #4584 and waiting-for-dev/devise-jwt#23
* Bug
Users that use devise-jwt, will not have the correct behavior of trackable
feature. As a request for APIs always requires authentication since there
is no session in APIs world, Devise counts +1 on every request since it
contains authentication info.
It happens because Devise has a trackable hook that updates the trackable
info everytime that the user is signed in by Warden.
* Fix
We are moving update_trackable_fields! from trackable hook (which was removed)
to sign_in_out and database_authenticatable. This way, update_trackable_fields!
is going to run only when the user signed in by Devise (only one time).
Used Rails' secure_compare method inside the definition of secure_compare. This will handle the empty strings comparison and return true when both the parameters are blank strings.
Fixes#4441
As reported in https://github.com/plataformatec/devise/issues/5071, if
for some reason, a user in the database had the `confirmation_token`
column as a blank string, Devise would confirm that user after receiving
a request with a blank `confirmation_token` parameter.
After this commit, a request sending a blank `confirmation_token`
parameter will receive a validation error.
For applications that have users with a blank `confirmation_token` in
the database, it's recommended to manually regenerate or to nullify
them.
* Fix specs on Rails 6 RC2
`ActiveRecord::MigrationContext` now has a `schema_migration` attribute.
Ref: https://github.com/rails/rails/pull/36439/files#diff-8d3c44120f7b67ff79e2fbe6a40d0ad6R1018
* Use `media_type` instead of `content_type`
Before Rails 6 RC2, the `ActionDispatch::Response#content_type` method
would return only the media part of the `Content-Type` header, without any
other parts. Now the `#content_type` method returns the entire header -
as it is - and `#media_type` should be used instead to get the previous
behavior.
Ref:
- https://github.com/rails/rails/pull/36034
- https://github.com/rails/rails/pull/36854
* Use render template instead of render file
Render file will need the full path in order to avoid security breaches.
In this particular case, there's no need to use render file, it's ok to
use render template.
Ref: https://github.com/rails/rails/pull/35688
* Don't set `represent_boolean_as_integer` on Rails 6
* Update comments [ci skip]
Forwarding methods to private methods is deprecated and produces a
warning after Ruby 2.4.
see: https://bugs.ruby-lang.org/issues/12782
To fix this issue I'm mocking patching webrat making RailsAdatper#response
method public since Webrat::Session is delegating functions to it.
Before setting this option, our test suite was giving the following warning:
```
DEPRECATION WARNING: Leaving `ActiveRecord::ConnectionAdapters::SQLite3Adapter.represent_boolean_as_integer`
set to false is deprecated. SQLite databases have used 't' and 'f' to serialize
boolean values and must have old data converted to 1 and 0 (its native boolean
serialization) before setting this flag to true. Conversion can be accomplished
by setting up a rake task which runs
ExampleModel.where("boolean_column = 't'").update_all(boolean_column: 1)
ExampleModel.where("boolean_column = 'f'").update_all(boolean_column: 0)
for all models and all boolean columns, after which the flag must be set to
true by adding the following to your application.rb file:
Rails.application.config.active_record.sqlite3.represent_boolean_as_integer = true
(called from <top (required)> at $PATH/devise/test/rails_app/app/active_record/user.rb:5)
```
After configuring `represent_boolean_as_integer = true` as specified
above, we don't have this warning anymore.
More info:
https://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/SQLite3Adapter.html#method-c-represent_boolean_as_integer
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.
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.
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
```
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
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.
The test uses `as_json` instead of `to_json` because `to_json` does `#dup` on `options` before it reaches `#serializable_hash` and the test would pass without the fix.
