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.
* Change the way to detect ActiveRecord vs Mongoid
Cause of **mongoid-paperclip** declaring *after_commit* callback while **mongoid** (and MongoDB) does not support it.
* Update test for ActiveRecord presence to handle Mongoid/ActiveRecord project
This fairly straightforward refactor extracts the most obtuse
portions of store_location_for into the following discrete
private methods:
- extract_path_from_location
- remove_domain_from_uri
- add_fragment_back_to_path
This may seem like indirection but it was very unclear what
operation was being performed on the location sent to
store_location_for prior to this change.
I considered documenting the behavior but the code seemed
like a prime candidate for method extraction.
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.
