vendor/rails/railties/doc/guides/source/actioncontroller_basics/filters.txt

   1 == Filters ==
   2
   3 Filters are methods that are run before, after or "around" a controller action. For example, one filter might check to see if the logged in user has the right credentials to access that particular controller or action. Filters are inherited, so if you set a filter on ApplicationController, it will be run on every controller in your application. A common, simple filter is one which requires that a user is logged in for an action to be run. You can define the filter method this way:
   4
   5 [source, ruby]
   6 ---------------------------------
   7 class ApplicationController < ActionController::Base
   8
   9 private
  10
  11   def require_login
  12     unless logged_in?
  13       flash[:error] = "You must be logged in to access this section"
  14       redirect_to new_login_url # Prevents the current action from running
  15     end
  16   end
  17
  18   # The logged_in? method simply returns true if the user is logged in and
  19   # false otherwise. It does this by "booleanizing" the current_user method
  20   # we created previously using a double ! operator. Note that this is not
  21   # common in Ruby and is discouraged unless you really mean to convert something
  22   # into true or false.
  23   def logged_in?
  24     !!current_user
  25   end
  26
  27 end
  28 ---------------------------------
  29
  30 The method simply stores an error message in the flash and redirects to the login form if the user is not logged in. If a before filter (a filter which is run before the action) renders or redirects, the action will not run. If there are additional filters scheduled to run after the rendering or redirecting filter, they are also cancelled. To use this filter in a controller, use the `before_filter` method:
  31
  32 [source, ruby]
  33 ---------------------------------
  34 class ApplicationController < ActionController::Base
  35
  36   before_filter :require_login
  37
  38 end
  39 ---------------------------------
  40
  41 In this example, the filter is added to ApplicationController and thus all controllers in the application. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_filter` :
  42
  43 [source, ruby]
  44 ---------------------------------
  45 class LoginsController < Application
  46
  47   skip_before_filter :require_login, :only => [:new, :create]
  48
  49 end
  50 ---------------------------------
  51
  52 Now, the +LoginsController+'s "new" and "create" actions will work as before without requiring the user to be logged in. The `:only` option is used to only skip this filter for these actions, and there is also an `:except` option which works the other way. These options can be used when adding filters too, so you can add a filter which only runs for selected actions in the first place.
  53
  54 === After Filters and Around Filters ===
  55
  56 In addition to the before filters, you can run filters after an action has run or both before and after. The after filter is similar to the before filter, but because the action has already been run it has access to the response data that's about to be sent to the client. Obviously, after filters can not stop the action from running. Around filters are responsible for running the action, but they can choose not to, which is the around filter's way of stopping it.
  57
  58 [source, ruby]
  59 ---------------------------------
  60 # Example taken from the Rails API filter documentation:
  61 # http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html
  62 class ApplicationController < Application
  63
  64   around_filter :catch_exceptions
  65
  66 private
  67
  68   def catch_exceptions
  69     yield
  70   rescue => exception
  71     logger.debug "Caught exception! #{exception}"
  72     raise
  73   end
  74
  75 end
  76 ---------------------------------
  77
  78 === Other Ways to Use Filters ===
  79
  80 While the most common way to use filters is by creating private methods and using *_filter to add them, there are two other ways to do the same thing.
  81
  82 The first is to use a block directly with the *_filter methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block:
  83
  84 [source, ruby]
  85 ---------------------------------
  86 class ApplicationController < ActionController::Base
  87
  88   before_filter { |controller| redirect_to new_login_url unless controller.send(:logged_in?) }
  89
  90 end
  91 ---------------------------------
  92
  93 Note that the filter in this case uses `send` because the `logged_in?` method is private and the filter is not run in the scope of the controller. This is not the recommended way to implement this particular filter, but in more simple cases it might be useful.
  94
  95 The second way is to use a class (actually, any object that responds to the right methods will do) to handle the filtering. This is useful in cases that are more complex than can not be implemented in a readable and reusable way using the two other methods. As an example, you could rewrite the login filter again to use a class:
  96
  97 [source, ruby]
  98 ---------------------------------
  99 class ApplicationController < ActionController::Base
 100
 101   before_filter LoginFilter
 102
 103 end
 104
 105 class LoginFilter
 106
 107   def self.filter(controller)
 108     unless logged_in?
 109       controller.flash[:error] = "You must be logged in to access this section"
 110       controller.redirect_to controller.new_login_url
 111     end
 112   end
 113
 114 end
 115 ---------------------------------
 116
 117 Again, this is not an ideal example for this filter, because it's not run in the scope of the controller but gets the controller passed as an argument. The filter class has a class method `filter` which gets run before or after the action, depending on if it's a before or after filter. Classes used as around filters can also use the same `filter` method, which will get run in the same way. The method must `yield` to execute the action. Alternatively, it can have both a `before` and an `after` method that are run before and after the action.
 118
 119 The Rails API documentation has link:http://api.rubyonrails.org/classes/ActionController/Filters/ClassMethods.html[more information on using filters].