In the controller where you want to skip a before filter specified in an inherited controller, you can tell rails to skip the filter class ApplicationController before_filter :authenticate_user! end class SessionsController < ApplicationController skip_before_filter :authenticate_user! end
Update for devise 4.x class ApplicationController < ActionController::Base before_filter :configure_permitted_parameters, if: :devise_controller? protected def configure_permitted_parameters devise_parameter_sanitizer.permit(:sign_up, keys: [:username]) devise_parameter_sanitizer.permit(:sign_in, keys: [:username]) devise_parameter_sanitizer.permit(:account_update, keys: [:username]) end end After adding both gems, devise will work as normal. Update: With the latest version of Devise 3.x, as described at devise#strong-parameters, the authentication key (normally the email field), and … Read more
Devise needs these three attributes on your model. Therefore, generate the following migration and run it. class AddLockableToExamples < ActiveRecord::Migration def change add_column :examples, :failed_attempts, :integer, default: 0 add_column :examples, :unlock_token, :string # Only if unlock strategy is :email or :both add_column :examples, :locked_at, :datetime end end Hope this saves someone else hours of google-fu.
Based on this SO answer you need to include the Devise::Test::ControllerHelpers module in your controller specs. Add the following to your rails_helper: RSpec.configure do |config| config.include Devise::Test::ControllerHelpers, type: :controller end
You commented on my similar question a bit ago, and I found an answer that might help you as well. Upgrading to Devise 3.1.0 left some ‘cruft’ in a view that I hadn’t touched in a while. According to this blog post, you need to change your Devise mailer to use @token instead of the … Read more
Found the answer sitting in the Devise Github wiki, Reading that helps. 😉 config.to_prepare do Devise::Mailer.layout “simple” # simple.haml or simple.erb Devise::Mailer.helper :mailer end Here is the reference of the wiki page: How To: Create custom layouts
By default Devise does route to root after it’s actions. There is a nice article about overriding these actions on the Devise Wiki, https://github.com/plataformatec/devise/wiki/How-To:-Redirect-to-a-specific-page-on-successful-sign-in Or you can go even farther by setting stored_locations_for(resource) to nil, and then have different redirects for each action, ie: after_sign_up_path(resource), after_sign_in_path(resource) and so on.
I’ve used them both, but not extensively. In my last project, I gave Devise a shot. I ended up using Rails-Warden instead. Devise is a full authentication framework built on top of Warden. To customize its looks, you use generators, then edit the resulting views. Its routes, and view logic are hard coded. For example, … Read more
I’m looking at solving the same problem today and since this is not answered, giving it a go =) Models Devise generates a User model if you installed by default. Remove the lines under devise. This is how mine looks like. devise :database_authenticatable, :registerable, :recoverable, :rememberable, :trackable, :validatable In attr_accessible, you may remove email, :password, … Read more
The easiest way is just removing :registerable devise module from the default list defined into your Model (the class name used for the application’s users, usually User). class User < ActiveRecord::Base devise :database_authenticatable, :registerable, :recoverable, :rememberable, :trackable, :validatable … end So you’ll have it like this: class User < ActiveRecord::Base devise :database_authenticatable, :recoverable, :rememberable, :trackable, … Read more