HTTPS clone URL
Subversion checkout URL
Authorizing controller actions
- 3rd party add ons
- Abilities in Database
- Ability for Other Users
- Ability Precedence
- Accessing request data
- Action Aliases
- Admin Namespace
- Authorization for Namespaced Controllers
- Authorization in Web Services
- Authorizing controller actions
- CanCan 2.0
- CanCan 2.0 Aliases
- Changing Defaults
- Checking Abilities
- Controller Authorization Example
- Custom Ability Methods
- Custom Actions
- Debugging Abilities
- Defining Abilities
- Defining Abilities with Blocks
- Defining Abilities with Hashes
- Ensure Authorization
- Exception Handling
- Fetching Records
- Inherited Resources
- Issue Collaborators
- Link Helpers
- Model Adapter
- Multiple can definitions (from 1.3)
- mvc deficiencies
- Nested Resources
- Non RESTful Controllers
- Other Authorization Solutions
- Rails API Gem
- Role Based Authorization
- Separate Role Model
- Separating Abilities
- Share Ability Definitions
- Testing Abilities
- Translating your app
- Upgrading to 1.1
- Upgrading to 1.3
- Upgrading to 1.4
- Upgrading to 1.5
- Upgrading to 1.6
Clone this wiki locally
You can use the
authorize! method to manually handle authorization in a controller action. This will raise a
CanCan::AccessDenied exception when the user does not have permission. See Exception Handling for how to react to this.
def show @project = Project.find(params[:project]) authorize! :show, @project end
However that can be tedious to apply to each action. Instead you can use the
load_and_authorize_resource method in your controller to load the resource into an instance variable and authorize it automatically for every action in that controller.
class ProductsController < ActionController::Base load_and_authorize_resource end
This is the same as calling
authorize_resource because they are two separate steps and you can choose to use one or the other.
class ProductsController < ActionController::Base load_resource authorize_resource end
As of CanCan 1.5 you can use the
skip_authorize_resource methods to skip any of the applied behavior and specify specific actions like in a before filter. For example.
class ProductsController < ActionController::Base load_and_authorize_resource skip_authorize_resource :only => :new end
By default this will apply to every action in the controller even if it is not one of the 7 RESTful actions. The action name will be passed in when authorizing. For example, if we have a
discontinue action on
ProductsController it will have this behavior.
class ProductsController < ActionController::Base load_and_authorize_resource def discontinue # Automatically does the following: # @product = Product.find(params[:id]) # authorize! :discontinue, @product end end
You can specify which actions to affect using the
:only options, just like a
load_and_authorize_resource :only => [:index, :show]
For this you can pass a name to skip_authorize_resource. For example:
class CommentsController < ApplicationController load_and_authorize_resource :post load_and_authorize_resource :through => :post skip_authorize_resource :only => :show skip_authorize_resource :post, :only => :show end
The first skip_authorize_resource skips authorization check for comment and the second for post. Both are needed if you want to skip all authorization checks for an action.
As of 1.4 the index action will load the collection resource using
def index # @products automatically set to Product.accessible_by(current_ability) end
If you want custom find options such as includes or pagination, you can build on this further since it is a scope.
def index @products = @products.includes(:category).page(params[:page]) end
@products variable will not be set initially if
Product does not respond to
accessible_by (such as if you aren't using a supported ORM). It will also not be set if you are only using a block in the
can definitions because there is no way to determine which records to fetch from the database.
These member actions simply fetch the record directly.
def show # @product automatically set to Product.find(params[:id]) end
As of 1.4 these builder actions will initialize the resource with the attributes in the hash conditions. For example, if we have this
can :manage, Product, :discontinued => false
Then the product will be built with that attribute in the controller.
@product = Product.new(:discontinued => false)
This way it will pass authorization when the user accesses the
The attributes are then overridden by whatever is passed by the user in
If the model is named differently than the controller, then you may explicitly name the model that should be loaded; however, you must specify that it is not a parent in a nested routing situation, ie:
class ArticlesController < ApplicationController load_and_authorize_resource :post, :parent => false end
If the model class is namespaced differently than the controller you will need to specify the
class ProductsController < ApplicationController load_and_authorize_resource :class => "Store::Product" end
If you want to fetch a resource by something other than
id it can be done so using the
load_resource :find_by => :permalink # will use find_by_permalink!(params[:id]) authorize_resource
The resource will only be loaded into an instance variable if it hasn't been already. This allows you to easily override how the loading happens in a separate
class BooksController < ApplicationController before_filter :find_published_book, :only => :show load_and_authorize_resource private def find_published_book @book = Book.released.find(params[:id]) end end
It is important that any custom loading behavior happens before the call to
load_and_authorize_resource. If you have
authorize_resource in your
ApplicationController then you need to use
prepend_before_filter to do the loading in the controller subclasses so it happens before authorization.
authorize_resource will make a before filter which calls
authorize!, passing the resource instance variable if it exists. If the instance variable isn't set (such as in the index action) it will pass in the class name. For example, if we have a
ProductsController it will do this before each action.
authorize!(params[:action].to_sym, @product || Product)
For additional information see the
authorize_resource methods in the RDoc.
If you ever update a User record which may be the current user, it will make the current ability for that request stale. This means any
can? checks will use the user record before it was updated. You will need to reset the
current_ability instance so it will be reloaded. Do the same for the
current_user if you are caching that too.
if @user.update_attributes(params[:user]) @current_ability = nil @current_user = nil # ... end