Here's a little trick I use: directly call the before_filter or after_filter class methods in the devise.rb initializer. For example, I have a prepare_for_mobile method that I want to apply as a before_filter to all of the Devise controller actions. This is what I have at the bottom of config/initializers/devise.rb:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Add some before filters to all Devise controllers. | |
[ | |
Devise::SessionsController, | |
Devise::RegistrationsController, | |
Devise::PasswordsController | |
].each do |devise_controller_class| | |
devise_controller_class.before_filter :prepare_for_mobile | |
end |
Note that this is exactly the same as if you had added the before_filter call directly inside these controllers. That means if you wanted to be more selective, you could just as easily do something like:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Devise::RegistrationsController.before_filter :check_for_invite_code, :only => :new |
IMPORTANT NOTE: This tactic only works reliably in the production environment. That is because in development mode, the Devise controller classes get reloaded on each request, but this config file that we've edited does not.
UPDATED 2/16/2012: See my follow-up post where I revisit this issue with a solution that works in both production and development environments.
1 comment:
Once again, a great tutorial man. The illustrative examples are good and also easy to read.Now all I have to do is implement what you teach. Thanks dude:)
Post a Comment