Given a lot of time has passed since the last v4.x release, and there's
been many changes (including breaking ones) merged to main, let's go
with an "RC" version before doing a final release.
If we don't hear any major issues, I plan to release a final version in
a couple of weeks.
Otherwise if we humanized the whole string, it could cause us to change
the output of strings with periods and maybe other side-effects, since
we're changing the whole string from i18n.
This is safer as it only changes the first char of the translated
message, and only if it is a match with the first translated auth key,
so we can more safely humanize & downcase all auth keys to interpolate
in the message whenever needed.
Also add changelog for the change.
"Invalid Email or password." is grammatically incorrect, a change
introduced a while ago by #4014.
Signed-off-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
It's an unauthenticated request, so return 401 Unauthorized like most
other similar requests.
Signed-off-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
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 empty strings.
Fixes#4441, #4829
In Rack v3.1.0, the symbol for HTTP status code 422 was changed from `:unprocessable_entity` to `:unprocessable_content`.
As a result, when using rack 3.2 with the following configuration in `config/initializers/devise.rb`, a warning is shown on login failure:
```ruby
# config/initializers/devise.rb
Devise.setup do |config|
...
config.responder.error_status = :unprocessable_entity
```
Warning message:
```sh
/path-to-app/vendor/bundle/ruby/3.4.0/gems/devise-4.9.4/lib/devise/failure_app.rb:80: warning: Status code :unprocessable_entity is deprecated and will be removed in a future version of Rack. Please use :unprocessable_content instead.
```
This warning can be resolved by updating the config as follows:
```diff
# config/initializers/devise.rb
Devise.setup do |config|
...
+ config.responder.error_status = :unprocessable_content
- config.responder.error_status = :unprocessable_entity
```
This fixes the root cause of the warning for new apps by adjusting the generated config during `$ rails generate devise:install` depending on the rack version, so new apps using newer Rack versions generate `error_status = :unprocessable_content` instead of `:unprocessable_entity`.
Existing apps are handled by [latest versions of Rails, which will now transparently convert the code under the hood to avoid the Rack warning](https://github.com/rails/rails/pull/53383), and Devise will use that translation layer when available in the failure app to prevent the warning there as well (since that isn't covered by Rails automatic conversion).
Signed-off-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
We need to explicitly pass the `locale` around from the options (passed
to `warden.authenticate!` for instance) or the `I18n.locale` when
logging out and redirecting the user via `throw :warden`, otherwise in a
multi-locale app we'd lose the locale previously set / passed around and
fallback to the default for that flash message.
This is a follow-up of the fixes in #5567 where we implemented the
locale passing logic down to the failure app, but it missed these places
where we were using `throw :warden`.
Closes#5812
https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/
We need to add `ostruct` as a dev dependency because it doesn't come
as a default gem with Ruby 4.0 anymore.
Lock minitest < 6 since v6 has some incompatibilities with released
versions of Rails that will be fixed in future versions.
This is something I didn't run into a few other gems, but SimpleForm
did, presumabily because it touches additional areas like AV tests.
This is no longer in Rails since v5, it's been extracted to
`protected_attributes`, and we're dropping support to older versions of
Rails in main.
https://github.com/rails/protected_attributes
All of these have been deprecated for years, if we're releasing a new
major version, let's take the opportunity to do some cleanup.
* Remove deprecated `:bypass` option from `sign_in` helper,
use `bypass_sign_in` instead.
* Remove deprecated `devise_error_messages!` helper,
use `render "devise/shared/error_messages", resource: resource` instead.
* Remove deprecated `scope` second argument from `sign_in(resource, :admin)`
controller test helper, use `sign_in(resource, scope: :admin)` instead.
* Remove deprecated `Devise::TestHelpers`,
use `Devise::Test::ControllerHelpers` instead.
Closes#5739
Devise hasn't been tested with Mongoid since Rails version 5, only 4.x was still running those tests.
This enables the tests again on all currently supported Rails versions, with their respective mongoid supported versions. There were a couple of minor tweaks to make it happen, namely:
* The way we were dropping the session before doesn't work in later versions so I changed back to calling `purge!` which appears to work fine. We used to call `Mongoid.purge!` but that changed in #4686.
* Some of the configs in the Rails test app were setting Active Record values when outside of the AR ORM tests, updated those to make sure they are not set when running mongoid ORM tests.
* The validations added to the shared admin code in tests were only checking for Rails version 5.1, but we need to use the same check for AR 5.1 that is used in code, otherwise it will try to use methods not available in mongoid there.
We pointed to github to fix issues with Ruby 2.7 and kwargs, but since
then a version 1.0.5 was released which includes those fixes.
There's a few more things in their main, but nothing we need if all is
green.
./devise/test/support/webrat/matchers.rb:6: warning:
Nokogiri::CSS.parse is deprecated and will be removed in a future
version of Nokogiri. Use Nokogiri::CSS::Parser#parse instead.
Update argument name for config.warden [ci skip]
The argument for the block passed to `config.warden` is no a `Warden::Manager` instance but a `Warden::Config` instance, but it is confusingly named `manager` in the generated file.
Renaming this to `warden_config` for clarity.
When ActionMailer is not defined we have empty app/mailers/devise/mailer.rb file and Zeitwerk doesn't
like that and errors with
```
expected file app/mailers/devise/mailer.rb to define constant Devise::Mailer
```
The fix is to tell Zeitwerk to ignore that file if ActionMailer constant if not defined.
I tried to write a spec for it but since specs are run in the same process it's hard to have two
Rails applications where one of them has ActionMailer define and the seconds one doesn't.
Starting from Rails 8.0, routes are lazy-loaded by default in test and development environments.
However, Devise's mappings are built during the routes loading phase.
To ensure it works correctly, we need to load the routes first before accessing @@mappings.
main is targetting a v5 with some possible breaking changes, for main
it's mainly dropping support for older Ruby/Rails versions, but more
might come.
[ci skip]
A common usage of I18n with different locales is to create some around
callback in the application controller that sets the locale for the
entire action, via params/url/user/etc., which ensure the locale is
respected for the duration of that action, and resets at the end.
Devise was not respecting the locale when the authenticate failed and
triggered the failure app, because that happens in a warden middleware
right up in the change, by that time the controller around callback had
already reset the locale back to its default, and the failure app would
just translate flash messages using the default locale.
Now we are passing the current locale down to the failure app via warden
options, and wrapping it with an around callback, which makes the
failure app respect the set I18n locale by the controller at the time
the authentication failure is triggered, working as expected. (much more
like a normal controller would.)
I chose to introduce a callback in the failure app so we could wrap the
whole `respond` action processing rather than adding individual `locale`
options to the `I18n.t` calls, because that should ensure other possible
`I18n.t` calls from overridden failure apps would respect the set locale
as well, and makes it more like one would implement in a controller. I
don't recommend people using callbacks in their own failure apps though,
as this is not going to be documented as a "feature" of failures apps,
it's considered "internal" and could be refactored at any point.
It is possible to override the locale with the new `i18n_locale` method,
which simply defaults to the passed locale from the controller.
Closes#5247Closes#5246
Related to: #3052, #4823, and possible others already closed.
Related to warden: (may be closed there afterwards)
https://github.com/wardencommunity/warden/issues/180https://github.com/wardencommunity/warden/issues/170
It's EOL but the current versions of Rails are still supporting it, so
it makes sense for us to keep supporting it as well. And it doesn't give
us any extra maintenance burden as older versions have been doing.
There was a change introduced in Rails 7.1 that causes all public
actions of non-abstract controllers to become action methods, even if
they happen to match the name of an internal method defined by abstract
`ActionController::Base` and such, which is the case with `_prefixes`.
This change was intentional, it allows for example to have an action
called `status`, which is an internal method, and that is properly
managed as an action method now. However, it broke Devise due to
overriding `_prefixes`, which is a public method of Action Controller.
To fix, we are simply ensuring we keep `_prefixes` as an internal method
rather than action method, which matches previous behavior for this
particular method/implementation in Devise.
Ref: https://github.com/rails/rails/pull/48699
There's some incompatibility issue with loofah there since it uses an
older version of nokogiri, so I'm locking it on those older versions to
try to get a green build again there.
We still support super old versions, yes, and it doesn't like `ensure`
without a `begin..end` unfortunately.
I plan to remove this support soon, but for now I don't want to stop
supporting it yet.
- ### Context
Since version 2.0.0, Omniauth no longer recognizes `GET` request
on the auth path (`/users/auth/<provider>`). `POST` is the only
verb that is by default recognized in order to mitigate CSRF
attack. 66110da85e/lib/omniauth/strategy.rb (L205)
Ultimatelly, when a user try to access `GET /users/auth/facebook`,
Devise [passthru action](6d32d2447c/app/controllers/devise/omniauth_callbacks_controller.rb (L6))
will be called which just return a raw 404 page.
### Problem
There is no problem per se and everything work. However the
advantage of not matching GET request at the router layer allows
to get that same 404 page stylized for "free" (Rails ending up
rendering the 404 page of the app).
I believe it's also more consistent and less surprising for users
if this passthru action don't get called.
### Drawback
An application can no longer override the `passthru` to perform
the logic it wants (i.e. redirect the user).
If this is a dealbreaker, feel free to close this PR :).
Rails allow procs and lambda with either zero or more argument. Devise
however always tried to call instance_eval on those values, which does
always pass one argument: self.
There was a PR to fix this specific problem in Devise https://github.com/heartcombo/devise/pull/4627,
before the arity check was fixed in rails itself: https://github.com/rails/rails/pull/30391.
But even if the problem was fixed in Rails, Devise was still calling
the proc/lambas with instance_eval. That meant the fix added to Rails
did not apply to Devise.
The fix is to let Rails handle the :from and :reply_to defaults. We do
that by unsetting the headers instead of trying to replicate Rails handling
in Devise. This lets Rails handle it when setting up the mailer.
In regular HTML `<br>` is a void element, so it
Many of the shared templates used by devise use `<br/>`
to separate lines, which is invalid html because `<br>`
doesn't need a closing tag or a closing slash. See the
WhatWG spec here:
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-br-element
Also, the WhatWG spec uses `<p>` tags to separate
`<label>` and `<input>` tags rather than `<br>`, see
here:
https://html.spec.whatwg.org/multipage/input.html
To clean this up I've replaced `<br/>` with paragraph
tags throughout all of the templates.
This reverts b86c1c241b
DEPRECATION WARNING: SchemaMigration no longer inherits from
ActiveRecord::Base. If you want to use the default connection, remove
this argument. If you want to use a specific connection, instantiate
MigrationContext with the connection's schema migration, for example
`MigrationContext.new(path, Dog.connection.schema_migration)`.
Even though this is considered an internal / non-public / nodoc method,
it seems some libraries relied on it internally, causing some breakage.
Known libraries so far are `devise-security` and
`devise-pwned_password`.
Closes#5580
Devise is able to work with a specific ORM, either Active Record or
Mongoid, but nothing stops apps from using multiple ORMs within the same
application -- they just need to pick one to use with Devise. That's
generally determined by the require that is added to the Devise
initializer, that will load up either ORM's extensions so you can call
things like `devise` on your model to set it up.
However, some conditional logic in Devise, more specifically around
dirty tracking, was only considering having Active Record loaded up
after a certain version, to determine which methods to call in parts of
the implementation. In a previous change we refactored all that dirty
tracking code into this `OrmDirtyTracking` module to make it easier to
view all the methods that were being conditionally called, and now we're
repurposing this into a more generic `Orm` module (that's nodoc'ed by
default) so that upon including it, we can conditionally include the
proper dirty tracking extensions but also check whether the including
model is really Active Record or not, so we can trigger the correct
dirty tracking behavior for Mongoid as well if both are loaded on the
same app, whereas previously the Mongoid behavior would always use the
new Active Record behavior, but support may differ.
While we are also working to ensure the latest versions of Mongoid are
fully running with Devise, this should improve the situation by giving
apps with multiple ORMs loaded a chance to rely on some of these Devise
bits of functionality better now that weren't working properly before
without some monkey-patching on their end.
Closes#5539Closes#4542
We have an number of conditions due to how dirty tracking changed around
Rails 5.1, that implement methods using one or another method call. I
might need more of this for mongo upgrades based on an initial
investigation, plus this makes the code really hard to reason about
sometimes with these many conditionals.
While I want to drop support for older versions of Rails soon, this
centralization of dirty methods that are used by devise conditionally
simplifies the usage considerably across the board, moves the version
condition to a single place, and will make it easier to refactor later
once we drop older Rails version by simply removing the `devise_*`
versions of the methods, alongside the prefix on the method calls for
the most part, since those methods follow the naming of the newer Rails
versions.
It appears some people use the recall functionality with a redirect
response, and Devise starting on version 4.9 was overriding that status
code to the configured `error_status` for better Turbo support, which
broke the redirect functionality / expectation.
While I don't think it's really great usage of the recall functionality,
or at least it was unexpected usage, it's been working like that
basically forever where recalling would use the status code of the
recalled action, so this at least keeps it more consistent with that
behavior by respecting redirects and keeping that response as a redirect
based on the configured status, which should also work with Turbo I
believe, and makes this less of a breaking change.
Closes#5570Closes#5561 (it was closed previously, but related / closes with an
actual change now.)
While introducing this on turbo, looks like no specific test was added,
so this at least covers that a bit.
It needs some conditional checks since not all supported Rails +
Responders version work with the customization, so there's one test for
the hardcoded status version too, which can be removed in the future.
Rails main / 7.1.0.alpha introduced a change to improve typography by
default, by converting all apostrophes to be single quotation marks.
https://github.com/rails/rails/pull/45463
The change caused all our text based matching to fail, this updates the
tests to ensure compatibility.
Model tests were changed to test against the error type & information
rather than the translated string, which I think is an improvement
overall that should make them a little less brittle. I thought of using
[of_kind?] but that isn't available on all Rails versions we currently
support, while `added?` is. The drawback is that `added?` require full
details like the `:confirmation` example which requires the related
attribute that is being confirmed, but that's a small price to pay.
Integration tests were changed to match on a regexp that accepts both
quotes. I could've used a simple `.` to match anything there, but
thought I'd just keep it specific for clarity on what it is really
expected to match there. Plus, since it's integration testing against a
rendered response body, it's better to match the actual text rather than
resort on other ways. (like using I18n directly, etc.)
[of_kind?] https://api.rubyonrails.org/classes/ActiveModel/Errors.html#method-i-of_kind-3F
We can't just "swap" those model properties, as that sets instance vars
on the classes that get reverted to their "previous" value, which ends
up leaving the instance vars set as `nil`. However, our logic for those
model/class properties actually checks for `defined?` as a way to
override them, and delegates up to `Devise` global config if they are
not defined, so leaving instance vars back with `nil` values isn't
enough, we need to actually remove them.
This introduces a new test helper specifically for overriding those
model configs so that we can do proper cleanup.
This is an attempt to address the Webrat / Nokogiri compatibility issue
[discussed here]. It monkeypatches Webrat to explicitly add the old
default arguments to the invocation of to_xpath.
Move monkey patch to its own file under test/support/webrat.
I really need to get rid of webrat.
Closes#5475
[discussed here] https://github.com/sparklemotion/nokogiri/issues/2469
Expand tests to check for the actual validatable exception message
This was raising a `FrozenError` on Ruby < 3 where interpolated strings
were considered frozen. This [changed in Ruby 3], since such strings are
dynamic there's no point in freezing them by default.
The test wasn't catching this because `FrozenError` actually inherits
from `RuntimeError`:
>> FrozenError.ancestors
=> [FrozenError, RuntimeError, StandardError, Exception, Object ...]
So the exception check passed. Now we're also checking for the error
message to ensure it raised the exception we really expected there.
Closes#5465
[changed in Ruby 3] https://bugs.ruby-lang.org/issues/17104
Co-authored-by: Martin <martin@edv-beratung-meier.de>
It is indeed recommended for consistency, but Rails will be able to find
the views under `devise/` due to inheritance still, so make that a bit
clearer in the readme docs about customizing controllers, explaining
that copying or moving the views is an optional step.
Closes#5526
[ci skip]
Albeit it's not super recommended, it's possible and even mentioned in
the changelog/wiki in case the app has some additional responder logic
that needs to be applied to Devise across the board.
Explain a bit more about how `data-confirm` and `data-method` need to be
updated to the turbo versions `data-turbo-confirm` and
`data-turbo-method`, respectively. (and depending on its usage.)
[ci skip]
There's some additional information in the wiki upgrade guide for those
interested, but most of it is covered in the changelog and should
suffice.
The post install message should help guide people upgrading to make sure
they know what to do in this new version, since some may be using Turbo
out there with custom responders and failure apps and those would have
to be removed in order to use these new changes fully. Hopefully that's
enough of a nudge for them.
Just want to have something different than the currently released
version to test out more easily. Plus, this is probably going to become
v4.9.0 final soon anyway.
Unfortunately we can't enforce the version in the gemspec because
responders only supports Rails 5.2 now, and Devise still supports
previous versions.
We'll drop support for those in a future major release, so for now I'm
not adding any version.
This also adds a warning in case someone is using an older version of
responders and tries to set the error/redirect statuses via Devise, so
that they know what to do (upgrade responders) in that case.
This changes the OmniAuth "sign in" links to use buttons, which can be
wrapped in an actual HTML form with a method POST, making them work
better with and without Turbo in the app. It doesn't require rails/ujs
anymore in case of a non-Turbo app, as it previously did with links +
method=POST.
Turbo is disabled for those OmniAuth buttons, as they simply don't work
trying to follow the redirect to the OmniAuth provider via fetch,
causing CORS issues/errors.
Rails master on Ruby 2.7/3.0 is failing with the following error:
Resolving dependencies...
Could not find compatible versions
Because every version of rails depends on RubyGems >= 3.3.13
and Gemfile-rails-main depends on rails >= 0,
RubyGems >= 3.3.13 is required.
So, because current RubyGems version is = 3.1.6,
version solving has failed.
Trying to run with the latest available rubygems to see if that can fix
the problem, but sticking to the "default" rubygems version on older
Ruby versions to avoid build issues there.
It appears we're getting a newer version of this multipart-post
dependency, which doesn't work well with Ruby 2.2 by using
`Object.deprecate_constant`, resulting in the following error:
.../multipart-post-2.2.0/lib/multipart/post/parts.rb:152:in `<top (required)>':
undefined method `deprecate_constant' for Object:Class (NoMethodError)
Hopefully by locking on a previous version we can just get the build
back to green for now.
This simplifies the logic considerably, as we don't need to reach out to
what seems more internal-ish implementation of Rails with the
interaction between the request and controller objects.
b925880914
Rails implemented a CSRF token storage strategy to allow storing the
CSRF tokens outside of the sessios (for example, in an encrypted
cookie), and changed how the value is kept around during the request
cycle, by using a request.env value.
We still want to ensure the final session value is cleaned correctly in
the test, but the implementation needed to change since we can't simply
delete from the session anymore, we need to make sure we call the Rails
methods for resetting the current storage strategy so it works with all
of them.
https://github.com/rails/rails/pull/44283
* Rails and Ruby versions follow the most recent to oldest, except for
Rails main, so we can keep the Gemfile the first one.
* Excluding specific matrix combinations based on the Gemfile first,
Ruby version next, and keep the same order (most recent -> oldest)
* Quote all Ruby versions to keep things consistent. It's required for
the '3.0' version to avoid the float issue where it'd use the latest
3.x instead.
When you copy the commands that have the terminal beginning of line symbol in front of them you now no longer need to first delete this before running the command
Use `AS::Dependencies` as before if we still can, otherwise use the new
direct `constantize` call for Rails 7+.
Leave a TODO to help remind us this can be removed once we drop support
to Rails versions prior to 7 in the future.
It appears setting the `rack.session` to a simple hash doesn't work
anymore as it now has a few additional methods Rails is relying on to
determine whether it's enabled or not:
https://github.com/rails/rails/pull/42231
Failure:
NoMethodError: undefined method `enabled?' for {}:Hash
rails (f55cdafe4b82) actionpack/lib/action_dispatch/middleware/flash.rb:62:in `commit_flash'
Turns we we don't seem to need to set `rack.session` for the tests here.
Changes deprecated `ActiveSupport::Dependencies.constantize(model_name)` to `model_name.constantize`
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
Remove `ActiveSupport::Dependencies.reference`
This was deleted from Rails: 14d4edd7c3
As far as I can tell, it was meant to add a performance boost at some point in the past but doesn't seem to do anything useful these days.
Update a couple other modules that still referred to `devise_for` to
point to `devise`, and make all of them more consistent. We can only
mention `devise`, that should be clear enough about it being options
for the model method.
Resetting failed attempts after sign in happened inside a warden hook
specific for the lockable module, but that was hidden inside the hook
implementation and didn't allow any user customization.
One such customization needed for example is to direct these updates to
a write DB when using a multi-DB setup. With the logic hidden in the
warden hook this wasn't possible, now that it's exposed in a model
method much like trackable, we can override the model method to wrap it
in a connection switch block for example, point to a write DB, and
simply call `super`.
Closes#5310
Related to #5264 and #5133
2.2.10 is causing the dependency resolution on Rails 6-0-stable to fail:
```
Bundler could not find compatible versions for gem "railties":
In Gemfile-rails-6-0:
devise was resolved to 4.7.3, which depends on
railties (>= 4.1.0)
rails was resolved to 6.0.3.5, which depends on
railties (= 6.0.3.5)
responders (~> 3.0) was resolved to 3.0.1, which depends on
railties (>= 5.0)
Took 27.49 seconds
```
https://github.com/heartcombo/devise/runs/1905780158?check_suite_focus=true#step:5:23
The `railties` version 6.0.3.5 should work, given the other two are
using >= declarations, but it fails in 2.2.10.
Downgrading to 2.2.9 works.
The test suite was failing on Rails 6.0 + Ruby 3 with errors like:
Expected "{\"errors\":\"#<ActiveModel::Errors:0x000055f2e6cb8188>\"}"
to include "{\"errors\":{".
The ActiveModel::Errors object wasn't being serialized to JSON as
expected, and this only happened with that combination of Ruby/Rails.
Upon further investigation, this was caused by a change in Ruby and
fixed in Rails in this PR: https://github.com/rails/rails/pull/39697
(which describes in more details the exact same problem and links to the
Ruby bug tracker with more information).
That fix was backported to 6-0-stable in June 2020, but hasn't been
officially released in a stable version yet: (there have been only
security fixes since then for 6.0)
75f6539d0e
Since the branch contains the fix, I'm pointing directly to it to get
the tests passing. We can't tell if there'll be a new stable 6.0 release
at this point, but hopefully yes, in which case we can go back at
pointing to it.
This allows us to remove the dependency on the XML serializer provided
by the external `activemodel-serializers-xml` gem, and eliminates the
following deprecation warning:
DEPRECATION WARNING: ActiveModel::Errors#to_xml is deprecated and
will be removed in Rails 6.2.
Please note: this does not mean Devise doesn't support XML, it simply
means our test suite will use JSON to test non-navigatable formats
instead of XML, for simplicity. Devise's job is not to test object
serialization, so as long as your objects properly serialize to
XML/JSON/any other format, it should work out of the box.
And remove dupe entry in the exclude matrix.
In order to get Ruby 3 working we needed to install `rexml` as part of
the test dependencies, only done on the main Gemfile (Rails 6.1) and the
6.0 versions. (which are the only ones supported by Ruby 3.)
Devise itself doesn't require `rexml` as it does nothing with it, but a
dependency we use during tests seem to require it. I was able to track
it down to omniauth-openid -> rack-openid -> ruby-openid requiring it:
13a88ad644/lib/openid/yadis/xrds.rb (L1)
So while we have tests using omniauth-openid, we'll need this require in
place as well. Ideally that upstream version of ruby-openid should have
it, but it seems that one isn't updated in a while.
I'm sure more people will hit issues so I'm trying to add more guidance
here about how to upgrade... maybe that should be in its own wiki but
I'll keep it all in the changelog for now.
* Make test for validation to be Rails 6.1 compatible
The `ActiveModel::Errors` has been changed in Rails 6.1.
https://github.com/rails/rails/pull/32313
* Add gemfile for Rails 6.1
* Add CI matrix for Rails 6.1
Seven year ago rails `session.keys` could be empty if the session was
not loaded yet.
To prevent an error the removed code was introduced
https://github.com/heartcombo/devise/issues/2660
Since then rails changed the behaviour and makes sure that the session
is loaded before someone wants to access any session keys
3498aacbbe
Which means the `session.empty?` is not needed anymore once Rails 5.2+
and upwards only supported.
Deprecate `BLACKLIST_FOR_SERIALIZATION` constant in favor of a more
descriptive name `UNSAFE_ATTRIBUTES_FOR_SERIALIZATION`, removing
unnecessary usage of the word `blacklist` from devise.
The previous constant still works but will emit a warning if used, to
allow anyone still depending on it to upgrade.
This includes an internal backport of the Rails `deprecate_constant`
implementation that exists on Rails 5.1+ to be able to deprecate it
properly in prior versions, while we support those. (which I intend to
drop soon.)
I ran into an issue where options[:except] is a frozen array, which
explodes when we try to concat values in `serializable_hash`. To fix this
we dup the `:except` option before concatenating with the other options
there.
Closes#5278.
This one has been showing up when running tests:
Deprecation warning: Expected string default value for '--orm'; got false (boolean).
This will be rejected in the future unless you explicitly pass the options
`check_default_type: false` or call `allow_incompatible_default_type!` in your code
You can silence deprecations warning by setting the environment variable THOR_SILENCE_DEPRECATION.
The deprecation of `devise_error_messages!` wasn't super clear on what
was happening and how to get rid of the message, not it has a more
detailed explanation with an example of what to look for and what to
replace it with.
Closes#5257.
This is warning on Ruby 2.7, and seems unnecessary since Rails 5+
adopted kwargs approach. We still need to handle the difference for
Rails < 5 for now, while we support it (which I would like to remove
soon.)
Mocha deprecation warning at
...../active_support/dependencies.rb:324:in `require':
Require 'mocha/test_unit', 'mocha/minitest' or 'mocha/api'
instead of 'mocha/setup'.
This reverts commit d85d45bcef.
My mistake: this section is about *not* using Devise when starting with
Rails and building authentication for the first time, therefore we
should not be linking to Devise specific resources here.
[ci skip]
This is essentially the same as `gemfiles/Gemfile.rails-6.0-stable`, but
I'm keeping both for now since I want to change the main `Gemfile` later
to point to Rails master (`6.1.0.alpha`), so then I won't need to
recreate the `6.0-stable` Gemfile again.
Not sure how/when this one was removed, probably just mistakenly, so
let's add it back for now, at least while we support multiple old Ruby /
Rails versions. (which I plan to remove support in the near future.)
* `changed?` behaviour has been updated
Due to 16ae3db5a5 `changed?` has been updated to check for dirtiness after save. The new method that behaves like the old `changed` is `saved_changes?`.
* Add comment to explain which method to used based on which rails version it is
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]
Comment incorrectly states that default method is "get", while line 228 of /lib/devise.rb sets "delete": "The default method used while signing out: @@sign_out_via = :delete"
Also bumped sqlite from 1.3.6 to 1.4 because besides conflicting with
the version that the sqlite adapter was trying to load [0], it is supported
officially since rails 6 [1].
Related:
[0] rails/rails#35153
[1] rails/rails#35844
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.
The command bin/test stop running single tests once Devise started to
support Rails 5.2. The problem is because we used `rails/test_unit/minitest_plugin`
and this file was moved to another place.
See: https://github.com/rails/rails/pull/29572
I'm not sure if we should require the `minitest-plugin` directly from
Rails like we were doing, I tried it and it didn't work. So I'm
changing this `bin/test` completely based on how Rails does that [here](https://github.com/rails/rails/blob/master/tools/test.rb)
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.
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.
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.
Use `autocomplete="new-password"` or `autocomplete="current-password"` to better signal to browsers and password managers how to handle the password fields.
This feature is especially useful for “change your password” and “new user” forms
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.
* 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.
* Fix missing validations on Signup
This commit fixes issue
https://github.com/plataformatec/devise/issues/4673
This removes `validate: false` from saving a record when `Trackable` is
in use.
* Add test case
* Add mongoid model
Active Record changed it's public API, so we should check against its
version instead of Rails as it is possible to use Rails 5.1 with Mongoid,
which still has the older Dirty API.
However, this patch does not fixes a scenario where an app has both
Active Record and Mongoid loaded. It should be fixed by either normalizing
the Mongoid/ActiveRecord API or replacing the conditional method
definitions with a shim layer that abstracts this away.
Rails 5.1 has deprecated render :text, and HEAD requests on the
omniauth callbacks passthru method is causing errors because the render
:text is non-existant, and there's no template to fall back to.
Replacing :text with :plain, adds a content-type type of text/plain and
also returns the previous message.
render :plain was supported back in rails 4.1.0
http://api.rubyonrails.org/v4.1.0/classes/ActionView/Helpers/RenderingHelper.html#method-i-render
Otherwise we'd be mistakenly displaying the original email in the
message (which is the same we're sending the message to).
Also tweak the messaging a bit in this case, to show that the email "is
being changed" (the change hasn't taken effect yet).
Related to #4455.
Related to issue #4397
This hotfix adds a string coercion to new_password paramenters when
trying to reset an user's password.
Before that, when a user submitted a password recovery form with the
new_password and new_password_confirmation params as nil, Devise would
sign in the user with a success notice but without actually changing the
password.
This better indicates what the setting is for, and when it's supposed to
be triggered.
We might eventually deprecate the existing password_change on in favor
of password_changed.
This adds a new setting `send_email_change_notification` which will
send an email to the original user email when their email is updated to
a new one.
It doesn't take into account the reconfirmable setting yet, it will be
added next, so that if confirmable is included and reconfirmable is
being used, the email will be triggered when the email change is
requested, not when confirmed (e.g when we store the email in
`unconfirmed_email`, not when it's later copied to `email` when that is
confirmed).
in the test we need to declare a subclass of ``Devise::Mailer`` to give
a block to mail call inside of method which has a corresponding view
template
there are propably better ways to test this, but this is pretty much the
use case for passing a block
ActionMailer's ``mail`` method may receive a block for customizing the mails
format
``devise_mail`` now has the same functionality by just
passing the block to ``mail`` call.
fixesplataformatec/devise#2341
This change is required to better support scenarios where records don't have
an `encrypted_password` column and the password is managed elsewhere (LDAP, for instance).
The move from `email_changed?` to loop through the `authentication_keys` is also
useful to support edge cases where users can authenticate with different attributes
besides their email.
Closes#3624.
Fast finish triggers multiple Slack notification and floods our OSS slack room,
and it is a known bug for a while.
Reference: travis-ci/travis-ci/issues/1696
* Add Devise::FailureApp#{relative_url_root, relative_url_root?}
Also support missing action_controller.relative_url_root configuration.
* Dry assignment of relative_url_root
Also this commit adds support for
Rails.application.config.action_controller.relative_url_root
Previously, a `NoMethodError` exception would be raised from here when the
middleware stack isn't present and Warden wasn't injected as expected
(like in a controller test). To foolproof ourselves, we now raise a more
informative error when `request.env['warden']` is `nil` so developers can
figure this out on their own instead of reaching to the issue tracker for
guidance.
The sign_in method permits the bypass option
that ignore the others options used. This behavior
has lead some users to a misconfusion what the
method really does.
This change deprecate the bypass option in favor
of a method that only does the sign in with bypass.
Closes#3981
The suggested omniauth path noted in the CHANGELOG.md under 4.0.0.rc2
did not work. It was missing an `_omniauth` in the middle of the
method name.
user_github_authorize_path => user_github_omniauth_authorize_path
Call send_on_create_confirmation_instructions in after_commit instead of after_create, I think this is no harm in general and it makes things like async job work.
Fix#4062
Set the new defaults for Devise 4.1
In our configuration template we explicit set some configurations as recommended defaults.
Now we are enforcing these configurations to be the defaults.
It also removes all warning code about this change.
The first value returned by token_generator.generate is
simply the return value of friendly_token so this code should
be equivalent.
The use of token_generator here dates back to when the
confirmation_token was stored as a digest, but that is no
longer true.
This removes an upgrade path that migrated the old serialization format
to the new one introduced. This was introduced in c22d755 (#2300)
3 years ago and should no longer be needed.
As has been seen in a previous pull request, some applications require
routes to be loaded before the code is eagerly loaded, which implies
that all Rails applications using Devise need to have routes reloaded
twice:
https://github.com/plataformatec/devise/pull/3241
This can incur a very significant slowdown for large apps that have a
lot of routes or a lot of controllers, so reloading should be optional.
This change add warnings for these configurations:
* strip_whitespace_keys - It is already explicit on config template, now
it will be the same of the template.
* email_regexp - In the new version this regexp will be more
permissive.
* reconfirmable - It is already explicit on config template, now
it will be the same of the template.
* skip_session_storage - It is already explicit on config template, now
it will be the same of the template.
* sign_out_via - It is already explicit on config template, now
it will be the same of the template.
These ones is important to change, since the configuration says current
explicit value are the default. It can lead to misunderstanging if users
remove the explicit configuration.
It also updates the template explicit values:
* Warns the `config.mailer_sender` is nil by default
* Update `config.password_length` to use the current default
* Make the e-mail configuration explicit
Now the config `extend_remember_period` is used to:
`true` - Every time the user authentication is validated, the
cookie expiration is updated.
`false` - Does not updates the cookie expiration.
Closes#3994
[A change in Rails 5](3979403781) left me hunting for hours on why I could no longer log in to my application. To save others the trouble, I thought it would be nice to note it in the README.
Rails 5 deprecates inheriting directly from `ActiveRecord::Migration` in
favor of inheriting from `ActiveRecord::Migration[5.0]` where `5.0` is
the `major.minor` version of Rails that the migration was originally
written to support.
h/t to b0ce189c69.
This was deprecated on rails/rails#23980.
We now generate scope and provider specific routes, like `user_facebook_omniauth_callback`
or `user_github_omniauth_callback`.
We could deprecate the `omniauth_authorize_path` in favor of the generated routes, but
the `shared/links.html.erb` depends on it to generate all omniauth links at once.
Closes#3983.
* Expand the explanation of why it fail.
* Raise a subclass of `Thor::Error` so the Thor doesn't output the exception
backtrace as it isn't useful for developers facing this error.
I'd like to remove the Hakiri badge from devise's README.
Since we do check in Gemfile and Gemfile.lock for development
and testing purposes (contrary to the popular belief that gems
don't need those files), Hakiri thinks Devise is a Rails app,
instead of a library/gem.
Depending on the Rails version that is locked in Gemfile.lock,
Hakiri will show several CVEs for Rails. But our Travis pipeline
builds against several Rails' branches, all of them updated.
And it is up to the developers using Devise to update
Rails in their apps.
Those warnings (Rails CVEs) don't make sense for devise.
Throughout the documentations, we are using 'encrypt' incorrectly.
Encrypt means that someone will eventually decrypt the message,
which is obviously not the case for Devise.
I'm changing the docs to use 'hashing' instead.
However, I left the database field as `encrypted_password` for now.
I'll update the db field in an upcoming PR.
Time objects aren't properly coerced back when using the JSON cookie serialization,
so we need to do it ourselves.
To avoid any new JSON serialization issues, we now store the `generated_at` as
an String with the timestamp seconds + miliseconds in the cookie but still the
previous JSON encoded format.
Thanks to @boblail at https://github.com/plataformatec/devise/pull/3917 for the
initial patch.
Devise::ParameterSanitizer has a new syntax for permitting additional
attributes to a model. This commit updates the generated controllers to
reflect that.
We no longer need to support the `BaseSanitizer` implementation for apps without
the Strong Parameters API, and this section is lacking a minimal set of
docs to document the expected behavior besides the `README` section.
This solves the issue where a package might do:
```
user = User.new
user.email = 'test@test.com'
token = user.generate_reset_token
user.save
send_reset_email(token)
```
Since the save clears the reset token, the user will receive a stale token that no longer works.
Closes#3774
The current implementation is opinionated about the resource should have
an "email" column on it if it is to be recoverable, which isn't
necessarily the case. For example, developers may decide to pull emails
out into their own model or have some other way of communicating
password resets to their users (e.g. text message)
I'm not sure there's an easy test to put together for this case, as
minitest doesn't make it very easy to stub the "email_changed?" to raise
an error. Happy to look into building another model in the
"test/rails_app" if you want to have this properly tested though? Or for
a nice way to get calls to "email_changed?" to raise; minitest isn't
a test framework I'm overly familiar with :).
As a side note, it would be nice if the Validatable module also took
this into account, I may raise another PR for that.
This comes off the back of comments on this commit:
e641b4b7b9
* Replace "the instance variable name in controller" with "the helper methods
names in controller".
Devise dose not define instance variable for controllers but define helper
methods for controllers.
* Replace "the name in routes" with "the scope name in routes".
`singular` is used as an argument of `devise_scope`.
* Add sample codes of routing and controller.
If a new user is created with a reset password token, the previous behavior
would automatically clear the token even when it was desired for setting
the password for the first time.
Our Simple Form generator shouldn't be responsible for generating the `mailer`
view directory, so we should skip it and let the Erb generator do the job.
Closes#3254.
The existing comment seems to be either outdated or obscure. I interpret it as meaning that configure_warden! is invoked by an 'initializer' block in class Devise::Engine, i.e. in lib/devise/rails.rb. However, as far as I can tell the only time the method is invoked is when ActionDispatch::Routing::RouteSet#finalize! is called, and this is aliased by devise to finalize_with_devise!.
Allow basic authentication to be case insensitive as per the HTTP 1.1 spec RFC 2068 Section 11
> It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
We have a particular client in production that has basic auth hard-coded as `basic` rather than `Basic` and devise is rejecting perfectly fine credentials. Making this small change has allowed us to authenticate this client with no issues.
I'm not hugely familiar with ruby internals vis a vis sclass semantics,
but this *probably* serves as a workaround for the MRI thread-safety
bug mentioned in #3505.
Beyond that, and even if this doesn't fix the thread-safety issue, per
[this blog post][1], `define_method` is recommended over `class_eval`
for performance (and, fwiw, readability) reasons anyway.
[1]: http://tenderlovemaking.com/2013/03/03/dynamic_method_definitions.html
This logic is generic and reusable -- hash a secret; and take an
unhashed secret and compare it to a hashed secret. This breaks this out
to make it reusable in other places. Specifically, we use this in our
own token auth at Bonobos that we plan to split out as a Devise
extension. This will make that possible without copy & pasting this
code.
Now that Rails 3.1 is not supported anymore, we don't need to implement
to_xml, since it does the right thing by calling serializable_hash.
This removes the class_eval need that existed to simplify the
implementation of both to_xml and serializable_hash.
Devise.available_router_name currently returns either
Devise.router_name or :main_app. As such, any redirecting is done
within either of those contexts. Which leads to undesirable redirects
for scopes that reside in an isolate_namespace mounted engine.
This commit makes it possible for FailureApp’s redirect behavior to be
performed in the context of the router_name given to devise_for.
Test case added to cover undesirable behavior. Without change to
lib/devise/failure_app.rb, test case throws exception.
In order to be more clear about the expectations of for authenticating, we use
`password.present?` so there is no confusion about the role of the `valid_password?`
method.
More info: https://github.com/plataformatec/devise/issues/3519
Introspecting the scope of an object can make it difficult to use
wrapper patterns. See issue plataformatec/devise#3307 for an example.
Allow objects to specify their scope explicitly by implementing
`devise_scope`.
Rails 5 will [not have `hide_action` any longer](https://github.com/rails/rails/pull/18371/files), as the Rails convention is to not expose private or protected methods as actions, thus obviating the need for `hide_action`.
Presumably, there is code inheriting from `DeviseController` that is
calling these helpers, so they cannot be private, so protected seems to
be the only way to get Devise working with Rails 5.
Due to bug in Ruby 2.2.0; The bug has been acknowledged and fixed in trunk.
When password comes in FormEncoded the result of `gsub` breaks when
peppered with `nil`.
This only adds pepper if defined on the model and works around this
bug.
See: 622f3f14b6
This reverts commit 43d0715238.
save() returns false only when validations failed. In this case, validations are
not performed. Therefore save() may never return a falsy value.
If save() fails, the appropriate exception is raised.
With certain ORMs, such as NoBrainer, save() never returns true/false, but
always raise an exception. This commit lift the incompatiblity.
This should still keep the devise lookup in the case that a customed scope is not passed as option, but if instead the custom scope is passed, then the find_message method will use it.
This is kind of useful, if i don't want overwrite the devise locale, and use different locale files, but keeping still the fallback of my devise locale.
It is obvious that this initializer should be executed before Rails build_middleware_stack as Omniauth is build on middleware.
Also it is obvious that we need that initializer to be executed after all config/initializers/* files (that is where devise.rb usually is).
The warden method in the Devise::TestHelpers module adds a Warden proxy
object to the request environment hash under the 'warden' key. Including
this module in your test case registers that method as a callback, which
runs before every test:
https://github.com/plataformatec/devise/blob/v3.4.1/lib/devise/test_helpers.rb#L12
The request object itself is created in a callback added by Rails:
https://github.com/rails/rails/blob/v4.2.0/actionpack/lib/action_controller/test_case.rb#L687
So before each test runs, the Rails callback creates the request object,
and then the Devise callback adds a Warden proxy object to it.
I was using the rspec-retry gem (https://github.com/y310/rspec-retry),
and noticed that my controller specs would always fail whenever they
were retried with this error:
NoMethodError: undefined method `authenticate!' for nil:NilClass
When rspec-retry re-runs a failed test, it runs the setup callbacks
again. The Rails callback creates a new request object, but because of
the memoization that was here before, the Devise callback wouldn't add a
Warden proxy to it, which was causing the error.
With this change, the Warden setup code will still only run once as long
as the request object stays the same, but if it changes a new Warden
proxy will be added to the new request object.
There's no real need to pass 2 variables to the view to figure that out,
we can simply display the message relying on whether or not the
`@minimum_password_length` variable is present.
- use the new build env on Travis (sudo: false) (docs coming soon)
faster vms, more cpu, more ram, faster vm boot time
- remove the custom caching for now as the new setup has a far better network
- add rails-head to the gemfile list as it wasn't there
caching is generally not recommended for libs like Devise as you want to test against the latest gem versions. Caching will use the min requirements available on the system instead of retrieving the latest.
On that note, it is also recommended to remove the Gemfile.lock from the repo. For now I have just 'rm'd it before 'bundle install'
Allow to ensure valid upon confirming.
We might want to consider confirmation status in validations. For example, maybe we want to require certain fields upon confirmation, but not at registration.
BCrypt has a limit of 72 characters for the password. Anything beyond 72
characters is truncated. This commit updates the validation to limit
passwords to less than 72 characters, keeping within the limitation.
As I've described [here](http://keepachangelog.com), it's quite useful to associate release version numbers with dates to get situated in a change log.
Hope you find this useful.
PS: While doing this I did notice that a release marked as yanked in the CHANGELOG was not showing up as yanked on RubyGems, hence #3289.
As we are already slicing the Hash, we must be sure that this method will send
a "safe" object down to the other finder methods that will use the Hash entries
to do the querying.
Depending on the test order, there might a moment when a test reloads the I18n
backend and another tries to store a translation, but since the backend wasn't
re-initialized the custom translations would be overriden when i18n loads the
translations from the en.yml file.
... is enabled.
The old code may cause conflicts when developing an engine (i.e. invalid
route name) and according to @josevalim the reason for it to remain is
unknown.
Until 4.2.0, any test suite based on the `TestCase` classes provided by Rails would
always run into alphabetical, but now they run in random order. For now, we ensure
that our tests always run in alphabetical order.
Related commit on rails/rails
6ffb29d24e
This was broken in Rails 4.2.0+ because the `@scope` object is no longer a Hash
but an internal structure that supports a better override/rollback flow for cases
like this. If we would only support Rails 4.2, this method could be something
like this:
```ruby
def with_devise_exclusive_scope(new_path, new_as, options)
overrides = { as: new_as, path: new_path, module: nil }
overrides.merge!(options.slice(:constraints, :defaults, :options))
@scope = @scope.new(overrides)
yield
ensure
@scope = @scope.parent
end
```
I was seeing the following in my console:
```
/home/vagrant/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/devise-3.2.4/app/controllers/devise_controller.rb:9: warning: `*' interpreted as argument prefix
/home/vagrant/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/devise-3.2.4/app/controllers/devise_controller.rb:10: warning: `*' interpreted as argument prefix
```
This change silences this warning.
This leaks into Devise mappings overriding the existing :admin one, so
depending on the test seed it fails like this:
$ TESTOPTS="--seed=9972" rake
==> Devise.orm = :active_record
Run options: --seed=9972
...
1) Failure:
MappingTest#test_allows_path_to_be_given [./test/mapping_test.rb:31]:
Expected: "admin_area"
Actual: "admin"
Using a different name should avoid any test randomization issues.
Previously the test was raising an ArgumentError by mistake:
ArgumentError: wrong number of arguments (0 for 1)
actionpack (4.1.4) lib/action_dispatch/routing/route_set.rb:328:in `eval_block'`
The #eval_block method expects a proc/lambda argument that can be
instance_exec'ed, not a real block. In the Rails implementation the block
is passed to #draw, which calls #eval_block internally passing the block
along, but as a Proc argument and not as a block.
Also the error we were raising from #devise_for was a RuntimeError,
changed to the expected ArgumentError. Adding an assertion on top of the
expected message should ensure we won't have this issue again.
This was introduced in 29da146c07, related
to #2802.
Also refactor tests to remove the custom failure app class only used
once in favor of an inline class for the specific test, makes it easier
to follow what's going on.
after_confirmation_path_for checks whether the user already signed in
by calling signed_in? after confirmation succeeded.
Since it was called without scope specification, the user treated as
signed in inappropriately when the user signed in as another resource
(such as 'admin').
Changes the behavior of `Devise.warden` such that calling it multiple
times with different blocks will result in a call to each block on
`Devise.configure_warden!` rather than "last block wins". This is
especially used for plugins that wish to extend warden functionality
without clobbering base app configuration or vice versa.
Only execute the `SessionsController#destroy` if there is a signed in
user, otherwise it will raise
`ActionController::InvalidAuthenticityToken`.
Fixes#2934.
Pushing the `Time` object inside the session has inconsistencies
across different serializers and we should use a more primitive type
so we don't need any specific parsing logic for the JSON serializer.
* this will avoid people (like me) loosing an hour trying to understand
why doing it "a little bit safer" with 20 stretches suddenly takes
60 seconds to do sign_up or sign_in. An example of such discussion is:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/399627
The default specified in the docs does not match up with the default
specified in the config.
See
cc8636cfed/lib/devise.rb (L127)
Changing the docs to read 6..128 with the config setting to 8..128 is
feared to cause confusion, so removing the default clause instead.
The updates are:
* Indicate that it is possible to pass a block to `super` to add custom
behaviour to some Devise controller actions without completely
overriding them.
* Move mailer configuration out of the section "Controller filters and
helpers".
* Consistently use Ruby 1.9's hash syntax, highlight code and capitalize
"Devise".
* Wording improvements
Right now if you try to use a route that you have defined in your `omniauth_callbacks` but you have not declared that resource to be `omniauthable` you will get a weird route missing error which causes the user to look in the routes for the fix:
```ruby
devise_for :users, controllers: {omniauth_callbacks: "users/omniauth_callbacks"}
```
This PR checks to see if the mapping of `:user` has the module `omniauthable` included in it when `omniauth_callbacks` is specified in the route. If it does not, an instructional error is raised:
```
Mapping omniauth_callbacks on a resource that is not omniauthable
Please add `devise :omniauthable` to the `User` model
```
Since we don't have authentication token, we don't have to check if
password is "X".
:authentication_token don't have to be in the blacklist for
serialization too.
This is used as a complement to `stored_location_for`.
Example:
Before authorizing with Omniauth;
store_location_for(:user, dashboard_path)
redirect_to user_omniauth_authorize_path(:facebook)
In our Omniauth callback
sign_in(user)
redirect_to stored_location_for(:user) || root_path
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.
This method is part of the protected API and is used by custom
encryption engines (like `devise-encryptable`) to hook the custom
encryption logic in the models.
Fixes#2730
+ @@last_attempt_warning
+ last_attempt? method;
* send :last_attempt key if it is the last attempt
+ test for last attempt
* update test to make two asserts
* update message
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."
- Move the default permitted parameters into ParameterSanitizer::PermittedParameters
- Add devise_permitted_parameters helper
- devise_permitted_parameters.add to add permitted parameters
- devise_permitted_parameters.remove to remove Devise's defaults
- devise_permitted_parameters.for to access the parameters for a given action
- Update 'Strong Parameters' section of README
Signed-off-by: José Valim <jose.valim@plataformatec.com.br>
I added an extra note in the section on creating a custom (namespaced) controller.
This controller needs to be created in a directory in order for it to work. Otherwise (for example when creating the controller in `app/controllers`) a `uninitialized constant Admins` error is thrown.
Also, fixed the Markdown formatting for the numbered lists in the README.
We could always generate a confirmation token but not sending a
confirmation email by invoking the skip_confirmation_notification!
method when creating the account.
But there were no way to do that when we were turning on reconfirmable
and updating email.
At times, validations may be skipped and no email address may be
provided. Such an instance comes when testing uniqueness validations of
specific attributes in a Devise model with confirmable, especially when
using Shoulda matchers.
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."
* Rename #get_constraints_given_method to #constraints_for to make the
method clear.
* The method name now is required.
* Use symbols instead of strings.
* Make #constraints_for a protected method.
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).
There are a couple of gotchas in the existing documentation
about the `send_devise_notification` hook.
1. The `after_commit` callback can be called multiple times
so you should clear the array otherwise any additional
invocations will trigger extra copies of the email.
2. The `after_commit` callback is only called when a record
is created or updated so you need to check for `new_record?`
or `changed?` before adding it to `pending_notifications`
otherwise it's okay to send it immediately.
The `new_record? || changed?` condition is necessary because
the latter isn't always true for new records, e.g:
>> User.new.changed?
=> false
[ci skip]
This was the previous functionality since we didn't set anything in the
application configuration. Now when using protected attributes gem, it
sets whitelist to true, forcing us to always declare the accessible
attributes, and this is not the case for the Admin model.
Previously inheriting from Devise::Mailer would not render default views
from devise when the inheriting mailer didn't have the view. Now it'll
correctly pick the default one from Devise::Mailer.
The id attribute is not Integer in Mongo, so it fails with something like:
NoMethodError: undefined method `+' for "5106fc06ee6da1ee44000002":Moped::BSON::ObjectId'`
With #next, it will work with both Integer and String ids, for both AR
and Mongo, returning a different id to test for filtered conditions.
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.
This avoids calling strip and downcase on globally configured keys that may
not exist on all devise models. Fixes#2204, a regression introduced by
PR #2135. Also included a note about the intentional use of respond_to.
For a point release upgrade, Devise should not throw an exception when trying
to downcase or strip globally configured keys. This would be a breaking
change in functionality and this test demonstrates the issue.
In DatabaseAuthenticatable#update_with_password, password is now deleted if
the current_password is invalid. dm-validations will not check the
confirmation in that case, so this test was failing in dm-devise.
Attribute unlock token is not present in the simple_form template,
therefore not being displayed by #error_notification.
This fix explicitily call #full_error on :unlock_token.
fixes#2143
Attribute confirmation token is not present in the simple_form template,
therefore not being displayed by #error_notification.
This fix explicitily call #full_error on :confirmation_token.
This has no actual changes to Devise itself, just fixes the failing
tests when running against Mongoid 3 instead of Mongoid 2.
Mocha has been locked at 0.10.0 since 0.12.0 raises an error when trying
to set an expectation on a frozen object.
Tests were updated to work with both AR and Mongoid, some cases the XML
serialization was slightly different but both were outputting correct
and valid XML, and the id/_id field mismatch is now handled.
An active field was missing from the test models for Mongoid, and the
invalid :null => true options in field were removed.
This is another failing test for #1994, a unit test for Lockable. Lockable's
#uanauthenticated_message should not return :locked if paranoid mode is on
and instead should return the generic :invalid response.
The _process_unauthenticated method in test_helper was returning
the response as the body. When setting rendering the text, it was
calling to_s on the response which would render something like
this: #<ActionDispatch::Response:0x007fb9e1efea00>. This change
renders the body of the response instead of the response itself
- Favor using update_attribute instead of constructor parameters in user
factory for tests
- Test for accurate error message when confirmation token is expired
- Don't check twice whether the confirmation period is expired
With this patch, functionality is added to expire the confirmation
tokens that are being sent by email.
For example, if a token is valid for 3 days only, it cannot be used for
confirmation on the 4th day.
In light of recent discussions around mass assignment security and
the alternate solution of using the controller to filter params, not the model,
a hook/helper is needed to be able to override how the params are filtered
before they are used to build the resource.
Code cleanup for returning headers instead of an empty string
when destroying sessions.
Lines 464 and 471 on test/integration/autenticatable_test.rb
were adjusted to assert on :no_content
find_for_authentication should be called during only during
an authentication process.
This reverts commit a4c9d5826d, reversing
changes made to f94b71038e.
This is also better for translations, because we can translate paragraph-wise.
signed_up_but_inactive and signed_up_but_locked are likely not needed,
but I wasn't sure how to best remove them.
failed attempts count gets reset. When the user tries to login with an incorrect password next,
the message shown is for invalid password instead of locked account since this check
depended mainly on failed attempts count.
This allows alternate ORMs to run compatibility setup code before
Authenticatable is included.
The particular issue for dm-devise is that DataMapper does not have a
before_validation method, which is called when Authenticatable is included
(as of plataformatec/devise@bd27bf76). dm-devise adds before_validation in
it's devise_modules_hook!
There is a delegator to get failure app, introduced in 4629bee and tuned
in 24b26026. The latter commit introduced a bit of logic, however, no
tests are included into commit. Needless to say this resulted in a
broken code.
The point is that `env["warden.options"][:scope]` returns a string.
However, `Devise.mappings` is a hash with symbol keys.
Adding tests and converting scope to symbol here.
It was impossible to accomplish this by providing a
custom #after_sign_out_path_for in ApplicationController because the
session gets destroyed before it is called. Furthermore,
resource_return_to is now used by default if it exists, so users won't
have to provide a custom #after_sign_out_path_for in that case.
Documentation states that authentication_keys should accept a hash with
values indicating whether or not each key is required. This was added in
b2066cc2 but tests only covered request_keys, and 29afe2d2 later broke
it with a << array operator.
- attr_accessible not set for test user model, making Serializable tests
inaccurate
- Mongoid does not `include_root_in_json` by default, so enable this for
consistency with AR tests
- Mark tests pending for Mongoid < 2.1 that fail there due to known bugs
- Add `:mongoid` key for i18n model labels
- Remove outdated shim of `update_attribute` that caused mass assignment
security to be applied (ugh, that took awhile to find)
Per josevalim, by setting {:format => false} in @scope[:options],
Rails will pick it up, without the need to alter each devise_*()
method individually.
On ruby-1.9.2-p136 I got the following error when using `root :to => "home"`:
actionpack-3.0.5/lib/action_dispatch/routing/mapper.rb:171:in `default_controller_and_action': missing :action (ArgumentError)
Specifying the action solves the problem.
(If using default authentication_keys or custom authentication_keys with email included)
Test written for Mongoid, not sure how to test for active_record yet.
config.pepper is used by both database_authenticatable and encryptable,
but encryptable requires database_authenticatable anyway, so it makes
more sense to have it in the database_authenticatable section.
This will make Devise::SessionsController return the authenticated object in the requested format instead of redirect the client to another page upon success authentication.
When using a token longer than approximately 45 characters, the base64 encoded string passed in
the HTTP_AUTHORIZATION header will contain newline characters. The existing implementation used
a regex which didn't handle this case correctly.
This comes with the benefit that if you change your password, all remember tokens expires, and it also requires one field less in the database.
The downside is that if you want remember_me_across_browser to be false, it won't work unless you use the token. It also requires you to be using database_authenticable.
Using salt is now the default in Devise.
The chance of someone to successfully guess a random token in the website is:
(number_of_users / 2388636399360109977557402041718133080829429159844757507642063199359529632522467783435119230976)
The forgetable hook will delete cookies based on the :scope in an
options hash but it was overwriting the options and setting them to
either an empty hash or a hash with a single :domain key. Because the
:scope was lost, the hook was trying to delete the 'remember__token'
instead of the more typical 'remember_user_token' cookie.
Two tests are to ensure that the callbacks are called at all. The other
two test ensure that the user parameter provided to the callback is not
nil.
Signed-off-by: José Valim <jose.valim@gmail.com>
This caused issues with OAuth header authentication.
Please note I have added a test but I'm not sure it works right as it doesn't fails without the change :-)
But it does fix failures in the oauth-plugin provider specs using devise.
RubyDoc.info is a new guy in the ruby community that was built to replace Rdoc.info. Actually, RubyDoc.info is a result of the merge betwenn yardoc.org/docs and rdoc.info.
The :mongoid group does not work in JRuby so the group
is only defined for the platform: 'ruby'.
In addition installing ruby-debug in JRuby is a manual process so
only include the dependency if we are using the platform: 'ruby'
Here are the steps necessary to run the devise tests in JRuby
using rvm:
rvm install jruby
rvm use jruby@devise --create
gem install bundler --pre
gem install jeweler
bundle install
rake test
You are now allowed to do:
devise_for :users do
# Non conventional sign_in route
get "/sign_in" => "devise/sessions#new"
end
And it should work as expected.
If you have non conventional routes and want to specify the scope for a controller, you can do that at the router level:
as :user do
get "/sign_in", :to => "devise/session#new"
end
This is saying: when accessing "/sign_in", devise should use the user scope. Meaning that users signed through that form will be signed to the user scope.
Devise 1.1.0 will be released soon. This new version will support activerecord and mongoid as default ORMs. From now on, Devise will prefer ORM extensions as gems since this is the best way to handle dependencies.
For example, to allow Devise to work with Datamapper, it requires at least activemodel, dm-rails and dm-timestamps. If the ORM support comes from Devise gem, we cannot add dm-rails and dm-timestamps as dependencies, relying on the developer and documentation to find these out and install them.
Other ORMs may still be added to Devise, as long as they are supported by the community, extend Devise test suite to have all tests passing and they necessarily use ActiveModel::Validations.
DM has a #save! method, so it's no longer needed. Having it call #save
caused #valid? to be called where tests were expecting validations to be
skipped.
In order to be more ActiveModel compliant, lets use persisted? whereever we can. Particularly for datamapper, new_record? causes api warnings. Better to stick to the ActiveModel api I think.
moving test specific == override part of the test models and not part of the Compatibility module included in all Mongoid docs. Made sure that nothing in devise itself uses this == between 2 different models, its purely for assert_equal
Test suite runs, however there's still some failing tests. This allows us to at least have a working test suite so they can fix these datamapper spec failures individually.
Added the ability to customize password length (via Devise.password_length) and the regular expression used for validating email (via Devise.email_regex)
We need to be sure require_no_authentication runs before other user filters that may call some Devise helper (ie current_xxx).
Conflicts:
app/controllers/devise/passwords_controller.rb
app/controllers/devise/registrations_controller.rb
app/controllers/devise/sessions_controller.rb
app/controllers/devise/unlocks_controller.rb
lib/devise/controllers/internal_helpers.rb
test/rails_app/app/controllers/application_controller.rb
From Rails' CHANGELOG
… Mail.body returns a Mail::Body class object, need to call #encoded or #decoded to get the string you want.
Signed-off-by: José Valim <jose.valim@gmail.com>
* Remove deprecated `scope` second argument from `sign_in(resource, :admin)` controller test helper, use `sign_in(resource, scope: :admin)` instead. [#5803](https://github.com/heartcombo/devise/pull/5803)
* Remove deprecated `Devise::TestHelpers`, use `Devise::Test::ControllerHelpers` instead. [#5803](https://github.com/heartcombo/devise/pull/5803)
* Remove `SecretKeyFinder` and use `app.secret_key_base` as the default secret key for `Devise.secret_key` if a custom `Devise.secret_key` is not provided.
This is potentially a breaking change because Devise previously used the following order to find a secret key:
Now, it always uses `application.secret_key_base`. Make sure you're using the same secret key after the upgrade; otherwise, previously generated tokens for `recoverable`, `lockable`, and `confirmable` will be invalid.
* Change password instructions button label on devise view from `Send me reset password instructions` to `Send me password reset instructions` [#5515](https://github.com/heartcombo/devise/pull/5515)
* Change `<br>` tags separating form elements to wrapping them in `<p>` tags [#5494](https://github.com/heartcombo/devise/pull/5494)
* Replace `[data-turbo-cache=false]` with `[data-turbo-temporary]` on `devise/shared/error_messages` partial. This has been [deprecated by Turbo since v7.3.0 (released on Mar 1, 2023)](https://github.com/hotwired/turbo/releases/tag/v7.3.0).
If you are using an older version of Turbo and the default devise template, you'll need to copy it over to your app and change that back to `[data-turbo-cache=false]`.
* enhancements
* Add Rails 8 support.
- Routes are lazy-loaded by default in test and development environments now so Devise loads them before `Devise.mappings` call. [#5728](https://github.com/heartcombo/devise/pull/5728)
* New apps using Rack 3.1+ will be generated using `config.responder.error_status = :unprocessable_content`, since [`:unprocessable_entity` has been deprecated by Rack](https://github.com/rack/rack/pull/2137).
Latest versions of [Rails transparently convert `:unprocessable_entity` -> `:unprocessable_content`](https://github.com/rails/rails/pull/53383), and Devise will use that in the failure app to avoid Rack deprecation warnings for apps that are configured with `:unprocessable_entity`. They can also simply change their `error_status` to `:unprocessable_content` in latest Rack versions to avoid the warning.
* Add Ruby 3.4 and 4.0 support.
* Reenable Mongoid test suite across all Rails 7+ versions, to ensure we continue supporting it. Changes to dirty tracking to support Mongoid 8.0+. [#5568](https://github.com/heartcombo/devise/pull/5568)
so it's possible to override `password_length` at runtime. [#5734](https://github.com/heartcombo/devise/pull/5734)
* bug fixes
* Make `Devise` work without `ActionMailer` when `Zeitwerk` autoloader is used. [#5731](https://github.com/heartcombo/devise/pull/5731)
* Handle defaults `:from` and `:reply_to` as procs correctly by delegating to Rails [#5595](https://github.com/heartcombo/devise/pull/5595)
* Use `OmniAuth.config.allowed_request_methods` as routing verbs for the auth path [#5508](https://github.com/heartcombo/devise/pull/5508)
* Handle `on` and `ON` as true values to check params [#5514](https://github.com/heartcombo/devise/pull/5514)
* Fix passing `format` option to `devise_for` [#5732](https://github.com/heartcombo/devise/pull/5732)
* Use `ActiveRecord::SecurityUtils.secure_compare` in `Devise.secure_compare` to match two empty strings correctly. [#4829](https://github.com/heartcombo/devise/pull/4829)
* Respond with `401 Unauthorized` for non-navigational requests to destroy the session when there is no authenticated resource. [#4878](https://github.com/heartcombo/devise/pull/4878)
* Fix incorrect grammar of invalid authentication message with capitalized attributes, e.g.: "Invalid Email or password" => "Invalid email or password". (originally introduced by [#4014](https://github.com/heartcombo/devise/pull/4014), released on v4.1.0) [#4834](https://github.com/heartcombo/devise/pull/4834)
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses, without explicit permission
* Other unethical or unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by sending an email to [heartcombo.oss@gmail.com](heartcombo.oss@gmail.com) or contacting one or more of the project maintainers.
This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org), version 1.2.0, available at [http://contributor-covenant.org/version/1/2/0/](http://contributor-covenant.org/version/1/2/0/)
Avoid opening new issues to ask questions in our issues tracker. Please go through
the project wiki, documentation and source code first, or try to ask your question
on [Stack Overflow](http://stackoverflow.com/questions/tagged/devise).
**If you find a security bug, do not report it through GitHub. Please send an
e-mail to [heartcombo.oss@gmail.com](mailto:heartcombo.oss@gmail.com)
instead.**
## Sending Pull Requests
Before sending a new Pull Request, take a look on existing Pull Requests and Issues
to see if the proposed change or fix has been discussed in the past, or if the
change was already implemented but not yet released.
We expect new Pull Requests to include enough tests for new or changed behavior,
and we aim to maintain everything as most backwards compatible as possible,
reserving breaking changes to be ship in major releases when necessary - you
can wrap the new code path with a setting toggle from the `Devise` module defined
as `false` by default to require developers to opt-in for the new behavior.
If your Pull Request includes new or changed behavior, be sure that the changes
are beneficial to a wide range of use cases or it's an application specific change
that might not be so valuable to other applications. Some changes can be introduced
as a new `devise-something` gem instead of belonging to the main codebase.
When adding new settings, you can take advantage of the [`Devise::Models.config`](https://github.com/heartcombo/devise/blob/245b1f9de0b3386b7913e14b60ea24f43b77feb0/lib/devise/models.rb#L13-L50) method to add class and instance level fallbacks
to the new setting.
We also welcome Pull Requests that improve our existing documentation (both our
`README.md` and the RDoc sections in the source code) or improve existing rough
edges in our API that might be blocking existing integrations or 3rd party gems.
## Other ways to contribute
We welcome anyone that wants to contribute to Devise to triage and reply to
open issues to help troubleshoot and fix existing bugs on Devise. Here is what
you can do:
* Help ensure that existing issues follows the recommendations from the
_[Reporting Issues](#reporting-issues)_ section, providing feedback to the issue's
author on what might be missing.
* Review and update the existing content of our [Wiki](https://github.com/heartcombo/devise/wiki)
with up to date instructions and code samples - the wiki was grown with several
different tutorials and references that we can't keep track of everything, so if
there is a page that showcases an integration or customization that you are
familiar with feel free to update it as necessary.
* Review existing Pull Requests, and testing patches against real existing
applications that use Devise.
Thanks again for your interest on contributing to the project!
Devise is a flexible authentication solution for Rails based on Warden. It:
* Is Rack based;
* Is a complete MVC solution based on Rails engines;
* Allows you to have multiple models signed in at the same time;
* Is based on a modularity concept: use only what you really need.
It's composed of 10 modules:
* [Database Authenticatable](https://www.rubydoc.info/gems/devise/Devise/Models/DatabaseAuthenticatable): hashes and stores a password in the database to validate the authenticity of a user while signing in. The authentication can be done both through POST requests or HTTP Basic Authentication.
* [Confirmable](https://www.rubydoc.info/gems/devise/Devise/Models/Confirmable): sends emails with confirmation instructions and verifies whether an account is already confirmed during sign in.
* [Recoverable](https://www.rubydoc.info/gems/devise/Devise/Models/Recoverable): resets the user password and sends reset instructions.
* [Registerable](https://www.rubydoc.info/gems/devise/Devise/Models/Registerable): handles signing up users through a registration process, also allowing them to edit and destroy their account.
* [Rememberable](https://www.rubydoc.info/gems/devise/Devise/Models/Rememberable): manages generating and clearing a token for remembering the user from a saved cookie.
* [Trackable](https://www.rubydoc.info/gems/devise/Devise/Models/Trackable): tracks sign in count, timestamps and IP address.
* [Timeoutable](https://www.rubydoc.info/gems/devise/Devise/Models/Timeoutable): expires sessions that have not been active in a specified period of time.
* [Validatable](https://www.rubydoc.info/gems/devise/Devise/Models/Validatable): provides validations of email and password. It's optional and can be customized, so you're able to define your own validations.
* [Lockable](https://www.rubydoc.info/gems/devise/Devise/Models/Lockable): locks an account after a specified number of failed sign-in attempts. Can unlock via email or after a specified time period.
The Devise Wiki has lots of additional information about Devise including many "how-to" articles and answers to the most frequently asked questions. Please browse the Wiki after finishing this README:
https://github.com/heartcombo/devise/wiki
### Bug reports
If you discover a problem with Devise, we would like to know about it. However, we ask that you please review these guidelines before submitting a bug report:
If you need to use Devise with previous versions of Rails, you can always run "gem server" from the command line after you install the gem to access the old documentation.
### Example applications
There are a few example applications available on GitHub that demonstrate various features of Devise with different versions of Rails. You can view them here:
Our community has created a number of extensions that add functionality above and beyond what is included with Devise. You can view a list of available extensions and add your own here:
You will usually want to write tests for your changes. To run the test suite, go into Devise's top-level directory and run `bundle install` and `bin/test`.
Devise works with multiple Ruby and Rails versions, and ActiveRecord and Mongoid ORMs, which means you can run the test suite with some modifiers: `DEVISE_ORM` and `BUNDLE_GEMFILE`.
#### DEVISE_ORM
Since Devise supports both Mongoid and ActiveRecord, we rely on this variable to run specific code for each ORM.
The default value of `DEVISE_ORM` is `active_record`. To run the tests for Mongoid, you can pass `mongoid`:
```
DEVISE_ORM=mongoid bin/test
==> Devise.orm = :mongoid
```
When running the tests for Mongoid, you will need to have a MongoDB server (version 2.0 or newer) running on your system.
Please note that the command output will show the variable value being used.
#### BUNDLE_GEMFILE
We can use this variable to tell bundler what Gemfile it should use (instead of the one in the current directory).
Inside the [gemfiles](https://github.com/heartcombo/devise/tree/main/gemfiles) directory, we have one for each version of Rails we support. When you send us a pull request, it may happen that the test suite breaks using some of them. If that's the case, you can simulate the same environment using the `BUNDLE_GEMFILE` variable.
For example, if the tests broke using Ruby 3.4 and Rails 8.0, you can do the following:
```bash
chruby 3.4.0 # or rbenv shell 3.4.0, or rvm use 3.4.0, etc.
If you are building your first Rails application, we recommend you *do not* use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we advise you to start a simple authentication system from scratch. Here's a few resources that should help you get started:
* Michael Hartl's online book: https://www.railstutorial.org/book/modeling_users
* Ryan Bates' Railscasts: http://railscasts.com/episodes/250-authentication-from-scratch and http://railscasts.com/episodes/250-authentication-from-scratch-revised
* Codecademy's Ruby on Rails: Authentication and Authorization: https://www.codecademy.com/learn/rails-auth
Once you have solidified your understanding of Rails and authentication mechanisms, we assure you Devise will be very pleasant to work with. :smiley:
## Getting started
Devise 5 works with Rails 7 onwards. Run:
```sh
bundle add devise
```
Next, you need to run the generator:
```console
rails generate devise:install
```
At this point, a number of instructions will appear in the console. Among these instructions, you'll need to set up the default URL options for the Devise mailer in each environment. Here is a possible configuration for `config/environments/development.rb`:
The generator will install an initializer which describes ALL of Devise's configuration options. It is *imperative* that you take a look at it. When you are done, you are ready to add Devise to any of your models using the generator.
In the following command you will replace `MODEL` with the class name used for the application’s users (it’s frequently `User` but could also be `Admin`). This will create a model (if one does not exist) and configure it with the default Devise modules. The generator also configures your `config/routes.rb` file to point to the Devise controller.
```console
rails generate devise MODEL
```
Next, check the MODEL for any additional configuration options you might want to add, such as confirmable or lockable. If you add an option, be sure to inspect the migration file (created by the generator if your ORM supports them) and uncomment the appropriate section. For example, if you add the confirmable option in the model, you'll need to uncomment the Confirmable section in the migration.
Then run `rails db:migrate`
You should restart your application after changing Devise's configuration options (this includes stopping spring). Otherwise, you will run into strange errors, for example, users being unable to login and route helpers being undefined.
### Controller filters and helpers
Devise will create some helpers to use inside your controllers and views. To set up a controller with user authentication, just add this before_action (assuming your devise model is 'User'):
```ruby
before_action:authenticate_user!
```
For Rails 5, note that `protect_from_forgery` is no longer prepended to the `before_action` chain, so if you have set `authenticate_user` before `protect_from_forgery`, your request will result in "Can't verify CSRF token authenticity." To resolve this, either change the order in which you call them, or use `protect_from_forgery prepend: true`.
If your devise model is something other than User, replace "_user" with "_yourmodel". The same logic applies to the instructions below.
To verify if a user is signed in, use the following helper:
```ruby
user_signed_in?
```
For the current signed-in user, this helper is available:
```ruby
current_user
```
You can access the session for this scope:
```ruby
user_session
```
After signing in a user, confirming the account or updating the password, Devise will look for a scoped root path to redirect to. For instance, when using a `:user` resource, the `user_root_path` will be used if it exists; otherwise, the default `root_path` will be used. This means that you need to set the root inside your routes:
```ruby
rootto:'home#index'
```
You can also override `after_sign_in_path_for` and `after_sign_out_path_for` to customize your redirect hooks.
Notice that if your Devise model is called `Member` instead of `User`, for example, then the helpers available are:
```ruby
before_action:authenticate_member!
member_signed_in?
current_member
member_session
```
### Configuring Models
The Devise method in your models also accepts some options to configure its modules. For example, you can choose the cost of the hashing algorithm with:
Besides `:stretches`, you can define `:pepper`, `:encryptor`, `:confirm_within`, `:remember_for`, `:timeout_in`, `:unlock_in` among other options. For more details, see the initializer file that was created when you invoked the "devise:install" generator described above. This file is usually located at `/config/initializers/devise.rb`.
### Strong Parameters
The Parameter Sanitizer API has changed for Devise 4 :warning:
*For previous Devise versions see https://github.com/heartcombo/devise/tree/3-stable#strong-parameters*
When you customize your own views, you may end up adding new attributes to forms. Rails 4 moved the parameter sanitization from the model to the controller, causing Devise to handle this concern at the controller as well.
There are just three actions in Devise that allow any set of parameters to be passed down to the model, therefore requiring sanitization. Their names and default permitted parameters are:
*`sign_in` (`Devise::SessionsController#create`) - Permits only the authentication keys (like `email`)
*`sign_up` (`Devise::RegistrationsController#create`) - Permits authentication keys plus `password` and `password_confirmation`
*`account_update` (`Devise::RegistrationsController#update`) - Permits authentication keys plus `password`, `password_confirmation` and `current_password`
In case you want to permit additional parameters (the lazy way™), you can do so using a simple before action in your `ApplicationController`:
The above works for any additional fields where the parameters are simple scalar types. If you have nested attributes (say you're using `accepts_nested_attributes_for`), then you will need to tell devise about those nestings and types:
If you have some checkboxes that express the roles a user may take on registration, the browser will send those selected checkboxes as an array. An array is not one of Strong Parameters' permitted scalars, so we need to configure Devise in the following way:
If you have multiple Devise models, you may want to set up a different parameter sanitizer per model. In this case, we recommend inheriting from `Devise::ParameterSanitizer` and adding your own logic:
The example above overrides the permitted parameters for the user to be both `:username` and `:email`. The non-lazy way to configure parameters would be by defining the before filter above in a custom controller. We detail how to configure and customize controllers in some sections below.
### Configuring views
We built Devise to help you quickly develop an application that uses authentication. However, we don't want to be in your way when you need to customize it.
Since Devise is an engine, all its views are packaged inside the gem. These views will help you get started, but after some time you may want to change them. If this is the case, you just need to invoke the following generator, and it will copy all views to your application:
```console
rails generate devise:views
```
If you have more than one Devise model in your application (such as `User` and `Admin`), you will notice that Devise uses the same views for all models. Fortunately, Devise offers an easy way to customize views. All you need to do is set `config.scoped_views = true` inside the `config/initializers/devise.rb` file.
After doing so, you will be able to have views based on the role like `users/sessions/new` and `admins/sessions/new`. If no view is found within the scope, Devise will use the default view at `devise/sessions/new`. You can also use the generator to generate scoped views:
```console
rails generate devise:views users
```
If you would like to generate only a few sets of views, like the ones for the `registerable` and `confirmable` module,
you can pass a list of views to the generator with the `-v` flag.
3. Recommended but not required: copy (or move) the views from `devise/sessions` to `users/sessions`. Rails will continue using the views from `devise/sessions` due to inheritance if you skip this step, but having the views matching the controller(s) keeps things consistent.
4. Finally, change or extend the desired controller actions.
You can completely override a controller action:
```ruby
class Users::SessionsController < Devise::SessionsController
def create
# custom sign-in code
end
end
```
Or you can simply add new behavior to it:
```ruby
class Users::SessionsController < Devise::SessionsController
def create
super do |resource|
BackgroundWorker.trigger(resource)
end
end
end
```
This is useful for triggering background jobs or logging events during certain actions.
Remember that Devise uses flash messages to let users know if sign in was successful or unsuccessful. Devise expects your application to call `flash[:notice]` and `flash[:alert]` as appropriate. Do not print the entire flash hash, print only specific keys. In some circumstances, Devise adds a `:timedout` key to the flash hash, which is not meant for display. Remove this key from the hash if you intend to print the entire hash.
### Configuring routes
Devise also ships with default routes. If you need to customize them, you should probably be able to do it through the devise_for method. It accepts several options like :class_name, :path_prefix and so on, including the possibility to change path names for I18n:
Be sure to check `devise_for` [documentation](https://www.rubydoc.info/gems/devise/ActionDispatch/Routing/Mapper#devise_for-instance_method) for details.
If you have the need for more deep customization, for instance to also allow "/sign_in" besides "/users/sign_in", all you need to do is create your routes normally and wrap them in a `devise_scope` block in the router:
```ruby
devise_scope :user do
get 'sign_in', to: 'devise/sessions#new'
end
```
This way, you tell Devise to use the scope `:user` when "/sign_in" is accessed. Notice `devise_scope` is also aliased as `as` in your router.
Please note: You will still need to add `devise_for` in your routes in order to use helper methods such as `current_user`.
```ruby
devise_for :users, skip: :all
```
### Hotwire/Turbo
Devise integrates with Hotwire/Turbo by treating such requests as navigational, and configuring certain responses for errors and redirects to match the expected behavior. New apps are generated with the following response configuration by default, and existing apps may opt-in by adding the config to their Devise initializers:
```ruby
Devise.setup do |config|
# ...
# When using Devise with Hotwire/Turbo, the http status for error responses
# and some redirects must match the following. The default in Devise for existing
# apps is `200 OK` and `302 Found` respectively, but new apps are generated with
# these new defaults that match Hotwire/Turbo behavior.
# Note: These might become the new default in future versions of Devise.
config.responder.error_status = :unprocessable_content # for Rack 3.1 or higher
# config.responder.error_status = :unprocessable_entity # for Rack 3.0 or lower
config.responder.redirect_status = :see_other
end
```
**Important**: these custom responses require the `responders` gem version to be `3.1.0` or higher, please make sure you update it if you're going to use this configuration. Check [this upgrade guide](https://github.com/heartcombo/devise/wiki/How-To:-Upgrade-to-Devise-4.9.0-[Hotwire-Turbo-integration]) for more info.
_Note_: the above statuses configuration may become the default for Devise in a future release.
There are a couple other changes you might need to make in your app to work with Hotwire/Turbo, if you're migrating from rails-ujs:
* The `data-confirm` option that adds a confirmation modal to buttons/forms before submission needs to change to `data-turbo-confirm`, so that Turbo handles those appropriately.
* The `data-method` option that sets the request method for link submissions needs to change to `data-turbo-method`. This is not necessary for `button_to` or `form`s since Turbo can handle those.
If you're setting up Devise to sign out via `:delete`, and you're using links (instead of buttons wrapped in a form) to sign out with the `method: :delete` option, they will need to be updated as described above. (Devise does not provide sign out links/buttons in its shared views.)
Make sure to inspect your views looking for those, and change appropriately.
### I18n
Devise uses flash messages with I18n, in conjunction with the flash keys :notice and :alert. To customize your app, you can set up your locale file:
```yaml
en:
devise:
sessions:
signed_in: 'Signed in successfully.'
```
You can also create distinct messages based on the resource you've configured using the singular name given in routes:
```yaml
en:
devise:
sessions:
user:
signed_in: 'Welcome user, you are signed in.'
admin:
signed_in: 'Hello admin!'
```
The Devise mailer uses a similar pattern to create subject messages:
```yaml
en:
devise:
mailer:
confirmation_instructions:
subject: 'Hello everybody!'
user_subject: 'Hello User! Please confirm your email'
reset_password_instructions:
subject: 'Reset instructions'
```
Take a look at our locale file to check all available messages. You may also be interested in one of the many translations that are available on our wiki:
https://github.com/heartcombo/devise/wiki/I18n
Caution: Devise Controllers inherit from ApplicationController. If your app uses multiple locales, you should be sure to set I18n.locale in ApplicationController.
### Test helpers
Devise includes some test helpers for controller and integration tests.
In order to use them, you need to include the respective module in your test
cases/specs.
### Controller tests
Controller tests require that you include `Devise::Test::IntegrationHelpers` on
your test case or its parent `ActionController::TestCase` superclass.
For Rails versions prior to 5, include `Devise::Test::ControllerHelpers` instead, since the superclass
for controller tests was changed to ActionDispatch::IntegrationTest
(for more details, see the [Integration tests](#integration-tests) section).
```ruby
class PostsControllerTest < ActionController::TestCase
include Devise::Test::IntegrationHelpers # Rails >= 5
end
```
```ruby
class PostsControllerTest < ActionController::TestCase
include Devise::Test::ControllerHelpers # Rails < 5
end
```
If you're using RSpec, you can put the following inside a file named
`spec/support/devise.rb` or in your `spec/spec_helper.rb` (or
`spec/rails_helper.rb` if you are using `rspec-rails`):
Devise comes with OmniAuth support out of the box to authenticate with other providers. To use it, simply specify your OmniAuth configuration in `config/initializers/devise.rb`:
Devise allows you to set up as many Devise models as you want. If you want to have an Admin model with just authentication and timeout features, in addition to the User model above, just run:
```ruby
# Create a migration with the required fields
create_table :admins do |t|
t.string :email
t.string :encrypted_password
t.timestamps null: false
end
# Inside your Admin model
devise :database_authenticatable, :timeoutable
# Inside your routes
devise_for :admins
# Inside your protected controller
before_action :authenticate_admin!
# Inside your controllers and views
admin_signed_in?
current_admin
admin_session
```
Alternatively, you can simply run the Devise generator.
Keep in mind that those models will have completely different routes. They **do not** and **cannot** share the same controller for sign in, sign out and so on. In case you want to have different roles sharing the same actions, we recommend that you use a role-based approach, by either providing a role column or using a dedicated gem for authorization.
### Active Job Integration
If you are using Active Job to deliver Action Mailer messages in the
background through a queuing back-end, you can send Devise emails through your
existing queue by overriding the `send_devise_notification` method in your model.
If you enable the [Recoverable](https://www.rubydoc.info/gems/devise/Devise/Models/Recoverable) module, note that a stolen password reset token could give an attacker access to your application. Devise takes effort to generate random, secure tokens, and stores only token digests in the database, never plaintext. However the default logging behavior in Rails can cause plaintext tokens to leak into log files:
1. Action Mailer logs the entire contents of all outgoing emails to the DEBUG level. Password reset tokens delivered to users in email will be leaked.
2. Active Job logs all arguments to every enqueued job at the INFO level. If you configure Devise to use `deliver_later` to send password reset emails, password reset tokens will be leaked.
Rails sets the production logger level to INFO by default. Consider changing your production logger level to WARN if you wish to prevent tokens from being leaked into your logs. In `config/environments/production.rb`:
```ruby
config.log_level = :warn
```
### Other ORMs
Devise supports ActiveRecord (default) and Mongoid. To select another ORM, simply require it in the initializer file.
### Rails API Mode
Rails 5+ has a built-in [API Mode](https://edgeguides.rubyonrails.org/api_app.html) which optimizes Rails for use as an API (only). Devise is _somewhat_ able to handle applications that are built in this mode without additional modifications in the sense that it should not raise exceptions and the like. But some issues may still arise during `development`/`testing`, as we still don't know the full extent of this compatibility. (For more information, see [issue #4947](https://github.com/heartcombo/devise/issues/4947/))
#### Supported Authentication Strategies
API-only applications don't support browser-based authentication via cookies, which is devise's default. Yet, devise can still provide authentication out of the box in those cases with the `http_authenticatable` strategy, which uses HTTP Basic Auth and authenticates the user on each request. (For more info, see this wiki article for [How To: Use HTTP Basic Authentication](https://github.com/heartcombo/devise/wiki/How-To:-Use-HTTP-Basic-Authentication))
The devise default for HTTP Auth is disabled, so it will need to be enabled in the devise initializer for the database strategy:
```ruby
config.http_authenticatable = [:database]
```
This restriction does not limit you from implementing custom warden strategies, either in your application or via gem-based extensions for devise.
A common authentication strategy for APIs is token-based authentication. For more information on extending devise to support this type of authentication and others, see the wiki article for [Simple Token Authentication Examples and alternatives](https://github.com/heartcombo/devise/wiki/How-To:-Simple-Token-Authentication-Example#alternatives) or this blog post on [Custom authentication methods with Devise](http://blog.plataformatec.com.br/2019/01/custom-authentication-methods-with-devise/).
#### Testing
API Mode changes the order of the middleware stack, and this can cause problems for `Devise::Test::IntegrationHelpers`. This problem usually surfaces as an ```undefined method `[]=' for nil:NilClass``` error when using integration test helpers, such as `#sign_in`. The solution is simply to reorder the middlewares by adding the following to test.rb:
For a deeper understanding of this, review [this issue](https://github.com/heartcombo/devise/issues/4696).
Additionally be mindful that without views supported, some email-based flows from Confirmable, Recoverable and Lockable are not supported directly at this time.
## Additional information
### Warden
Devise is based on Warden, which is a general Rack authentication framework created by Daniel Neighman. We encourage you to read more about Warden here:
https://github.com/wardencommunity/warden
## License
MIT License.
Copyright 2020-CURRENT Rafael França, Carlos Antonio da Silva.
Copyright 2009-2019 Plataformatec.
The Devise logo is licensed under [Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License](https://creativecommons.org/licenses/by-nc-nd/4.0/).
Devise is a flexible authentication solution for Rails based on Warden. It:
* Is Rack based;
* Is a complete MVC solution based on Rails engines;
* Allows you to have multiple roles (or models/scopes) signed in at the same time;
* Is based on a modularity concept: use just what you really need.
Right now it's composed of 12 modules:
* Authenticatable: responsible for encrypting password and validating authenticity of a user while signing in.
* Token Authenticatable: validates authenticity of a user while signing in using an authentication token (also known as "single access token").
* HttpAuthenticatable: sign in users using basic HTTP authentication.
* Confirmable: responsible for verifying whether an account is already confirmed to sign in, and to send emails with confirmation instructions.
* Recoverable: takes care of reseting the user password and send reset instructions.
* Registerable: handles signing up users through a registration process.
* Rememberable: manages generating and clearing token for remember the user from a saved cookie.
* Trackable: tracks sign in count, timestamps and ip.
* Timeoutable: expires sessions without activity in a certain period of time.
* Validatable: creates all needed validations for email and password. It's totally optional, so you're able to to customize validations by yourself.
* Lockable: takes care of locking an account based on the number of failed sign in attempts. Handles unlock via expire and email.
* Activatable: if you need to activate accounts by other means, which are not through confirmation, use this module.
There's an example application using Devise at http://github.com/plataformatec/devise_example .
== Dependencies
Devise is based on Warden (http://github.com/hassox/warden), a Rack Authentication Framework so you need to install it as a gem. Please ensure you have it installed in order to use devise (see installation below).
== Installation
All gems are on gemcutter, so you need to add gemcutter to your sources if you haven't yet:
sudo gem sources -a http://gemcutter.org/
Install warden gem if you don't have it installed (requires 0.6.4 or higher):
sudo gem install warden
Install devise gem:
sudo gem install devise
Configure warden and devise gems inside your app:
config.gem 'warden'
config.gem 'devise'
Run the generator:
ruby script/generate devise_install
And you're ready to go. The generator will install an initializer which describes ALL Devise's configuration options, so be sure to take a look at it and the documentation as well:
http://rdoc.info/projects/plataformatec/devise
== Basic Usage
This is a walkthrough with all steps you need to setup a devise resource, including model, migration, route files, and optional configuration. You MUST also check out the *Generators* section below to help you start.
Devise must be set up within the model (or models) you want to use, and devise routes must be created inside your config/routes.rb file.
We're assuming here you want a User model with some modules, as outlined below:
After you choose which modules to use, you need to setup your migrations. Luckily, devise has some helpers to save you from this boring work:
create_table :users do |t|
t.authenticatable
t.confirmable
t.recoverable
t.rememberable
t.trackable
t.timestamps
end
Remember that Devise don't rely on _attr_accessible_ or _attr_protected_ inside its modules, so be sure to setup what attributes are accessible or protected in your model.
The next setup after setting up your model is to configure your routes. You do this by opening up your config/routes.rb and adding:
map.devise_for :users
This is going to look inside you User model and create a set of needed routes (you can see them by running `rake routes`).
There are also some options available for configuring your routes, as :class_name (to set the class for that route), :path_prefix, :as and :path_names, where the last two have the same meaning as in common routes. The available :path_names are:
Be sure to check devise_for documentation for detailed description.
After this steps, run your migrations, and you are ready to go! But don't finish reading, we still have a lot to tell you:
== Controller filters and helpers
Devise is gonna create some helpers to use inside your controllers and views. To setup a controller that needs user authentication, just add this before_filter:
before_filter :authenticate_user!
To verify if a user is signed in, you have the following helper:
user_signed_in?
And to get the current signed in user this helper is available:
current_user
You have also access to the session for this scope:
user_session
After signing in a user, confirming it's account or updating it's password, devise will look for a scoped root path to redirect. Example: For a :user resource, it will use user_root_path if it exists, otherwise default root_path will be used. This means that you need to set the root inside your routes:
map.root :controller => 'home'
You can also overwrite after_sign_in_path_for and after_sign_out_path_for to customize better your redirect hooks.
Finally, you also need to setup default url options for the mailer in each environment. Here's is the configuration for config/environments/development.rb:
Devise let's you setup as many roles as you want, so let's say you already have this User model and also want an Admin model with just authentication, trackable, lockable and timeoutable stuff and none of confirmation or password recovery. Just follow the same steps:
Devise comes with some generators to help you start:
ruby script/generate devise_install
This will generate an initializer, with a description of all configuration values. You can also generate models through:
ruby script/generate devise Model
A model configured with all devise modules and attr_accessible for default fields will be created. The generator will also create the migration and configure your routes for devise.
== Model configuration
The devise method in your models also accept some options to configure its modules. For example, you can chose which encryptor to use in authenticatable:
Besides :encryptor, you can provide :pepper, :stretches, :confirm_within, :remember_for, :timeout_in, :unlock_in and others. All those are describer in the initializer created when you invoke the devise_install generator describer above.
== Views
Since devise is an engine, it has all default views inside the gem. They are good to get you started, but you will want to customize them at some point. And Devise has a generator to make copy them all to your application:
ruby script/generate devise_views
By default Devise will use the same views for all roles you have. But what if you need so different views to each of them? Devise also has an easy way to accomplish it: just setup config.scoped_views to true inside "config/initializers/devise.rb".
After doing so you will be able to have views based on the scope like 'sessions/users/new' and 'sessions/admin/new'. If no view is found within the scope, Devise will fallback to the default view.
Devise uses flash messages to let users know if their login is successful or not. Devise expects your application to call 'flash[:notice]' and 'flash[:alert]' as appropriate.
== I18n
Devise uses flash messages with I18n with the flash keys :success and :failure. To customize your app, you can setup your locale file this way:
en:
devise:
sessions:
signed_in: 'Signed in successfully.'
You can also create distinct messages based on the resource you've configured using the singular name given in routes:
en:
devise:
sessions:
user:
signed_in: 'Welcome user, you are signed in.'
admin:
signed_in: 'Hello admin!'
Devise mailer uses the same pattern to create subject messages:
en:
devise:
mailer:
confirmation_instructions: 'Hello everybody!'
user:
confirmation_instructions: 'Hello User! Please confirm your email'
reset_password_instructions: 'Reset instructions'
Take a look at our locale file to check all available messages.
== Test helpers
Devise includes some tests helpers for functional specs. To use them, you just need to include Devise::TestHelpers in your test class and use the sign_in and sign_out method. Such methods have the same signature as in controllers:
sign_in :user, @user # sign_in(scope, resource)
sign_in @user # sign_in(resource)
sign_out :user # sign_out(scope)
sign_out @user # sign_out(resource)
You can include the Devise Test Helpers in all of your tests by adding the following to the bottom of your test/test_helper.rb or spec/spec_helper.rb file:
class ActionController::TestCase
include Devise::TestHelpers
end
Do not use such helpers for integration tests like Cucumber, Webrat... Just fill in the form or explicitly set the user in session. For more tips, check the wiki (http://wiki.github.com/plataformatec/devise).
== Migrating from other solutions
Devise implements encryption strategies for Clearance, Authlogic and Restful-Authentication. To make use of it set the desired encryptor in the encryptor initializer config option. You might also need to rename your encrypted password and salt columns to match Devises's one (encrypted_password and password_salt).
== Other ORMs
Devise supports both ActiveRecord (default) and MongoMapper, and has experimental Datamapper supports (in a sense that Devise test suite does not run completely with Datamapper). To choose other ORM, you just need to configure it in the initializer file.
== TODO
Please refer to TODO file.
== Maintainers
* José Valim (http://github.com/josevalim)
* Carlos Antônio da Silva (http://github.com/carlosantoniodasilva)
== Contributors
We have a long running list of contributors. Check them in the CHANGELOG or do `git shortlog -s -n` in the cloned repository.
== Bugs and Feedback
If you discover any bugs or want to drop a line, feel free to create an issue on
# Additional translations at https://github.com/heartcombo/devise/wiki/I18n
en:
devise:
confirmations:
confirmed:"Your email address has been successfully confirmed."
send_instructions:"You will receive an email with instructions for how to confirm your email address in a few minutes."
send_paranoid_instructions:"If your email address exists in our database, you will receive an email with instructions for how to confirm your email address in a few minutes."
failure:
already_authenticated:"You are already signed in."
inactive:"Your account is not activated yet."
invalid:"Invalid %{authentication_keys} or password."
locked:"Your account is locked."
last_attempt:"You have one more attempt before your account is locked."
not_found_in_database:"Invalid %{authentication_keys} or password."
timeout:"Your session expired. Please sign in again to continue."
unauthenticated:"You need to sign in or sign up before continuing."
unconfirmed:"You have to confirm your email address before continuing."
mailer:
confirmation_instructions:
subject:"Confirmation instructions"
reset_password_instructions:
subject:"Reset password instructions"
unlock_instructions:
subject:"Unlock instructions"
email_changed:
subject:"Email Changed"
password_change:
subject:"Password Changed"
omniauth_callbacks:
failure:"Could not authenticate you from %{kind} because \"%{reason}\"."
success:"Successfully authenticated from %{kind} account."
passwords:
no_token:"You can't access this page without coming from a password reset email. If you do come from a password reset email, please make sure you used the full URL provided."
send_instructions:"You will receive an email with instructions on how to reset your password in a few minutes."
send_paranoid_instructions:"If your email address exists in our database, you will receive a password recovery link at your email address in a few minutes."
updated:"Your password has been changed successfully. You are now signed in."
updated_not_active:"Your password has been changed successfully."
registrations:
destroyed:"Bye! Your account has been successfully cancelled. We hope to see you again soon."
signed_up:"Welcome! You have signed up successfully."
signed_up_but_inactive:"You have signed up successfully. However, we could not sign you in because your account is not yet activated."
signed_up_but_locked:"You have signed up successfully. However, we could not sign you in because your account is locked."
signed_up_but_unconfirmed:"A message with a confirmation link has been sent to your email address. Please follow the link to activate your account."
update_needs_confirmation:"You updated your account successfully, but we need to verify your new email address. Please check your email and follow the confirmation link to confirm your new email address."
updated:"Your account has been updated successfully."
updated_but_not_signed_in:"Your account has been updated successfully, but since your password was changed, you need to sign in again."
sessions:
signed_in:"Signed in successfully."
signed_out:"Signed out successfully."
already_signed_out:"Signed out successfully."
unlocks:
send_instructions:"You will receive an email with instructions for how to unlock your account in a few minutes."
send_paranoid_instructions:"If your account exists, you will receive an email with instructions for how to unlock it in a few minutes."
unlocked:"Your account has been unlocked successfully. Please sign in to continue."
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
