Module: CanCan::Ability
- Defined in:
- lib/cancan/ability.rb
Overview
This module is designed to be included into an Ability class. This will provide the “can” methods for defining and checking abilities.
class Ability
include CanCan::Ability
def initialize(user)
if user.admin?
can :manage, :all
else
can :read, :all
end
end
end
Instance Method Summary collapse
-
#alias_action(*args) ⇒ Object
Alias one or more actions into another one.
-
#aliased_actions ⇒ Object
Returns a hash of aliased actions.
-
#can(action, subject, conditions = nil, &block) ⇒ Object
Defines which abilities are allowed using two arguments.
-
#can?(action, subject, *extra_args) ⇒ Boolean
Use to check the user’s permission for a given action and object.
-
#cannot(action, subject, conditions = nil, &block) ⇒ Object
Define an ability which cannot be done.
-
#cannot?(*args) ⇒ Boolean
Convenience method which works the same as “can?” but returns the opposite value.
-
#clear_aliased_actions ⇒ Object
Removes previously aliased actions including the defaults.
-
#conditions(action, subject) ⇒ Object
Returns a hash of conditions which match the given ability.
Instance Method Details
#alias_action(*args) ⇒ Object
Alias one or more actions into another one.
alias_action :update, :destroy, :to => :modify
can :modify, Comment
Then :modify permission will apply to both :update and :destroy requests.
can? :update, Comment # => true
can? :destroy, Comment # => true
This only works in one direction. Passing the aliased action into the “can?” call will not work because aliases are meant to generate more generic actions.
alias_action :update, :destroy, :to => :modify
can :update, Comment
can? :modify, Comment # => false
Unless that exact alias is used.
can :modify, Comment
can? :modify, Comment # => true
The following aliases are added by default for conveniently mapping common controller actions.
alias_action :index, :show, :to => :read
alias_action :new, :to => :create
alias_action :edit, :to => :update
This way one can use params in the controller to determine the permission.
170 171 172 173 174 |
# File 'lib/cancan/ability.rb', line 170 def alias_action(*args) target = args.pop[:to] aliased_actions[target] ||= [] aliased_actions[target] += args end |
#aliased_actions ⇒ Object
Returns a hash of aliased actions. The key is the target and the value is an array of actions aliasing the key.
177 178 179 |
# File 'lib/cancan/ability.rb', line 177 def aliased_actions @aliased_actions ||= default_alias_actions end |
#can(action, subject, conditions = nil, &block) ⇒ Object
Defines which abilities are allowed using two arguments. The first one is the action you’re setting the permission for, the second one is the class of object you’re setting it on.
can :update, Article
You can pass an array for either of these parameters to match any one.
can [:update, :destroy], [Article, Comment]
In this case the user has the ability to update or destroy both articles and comments.
You can pass a hash of conditions as the third argument.
can :read, Project, :active => true, :user_id => user.id
Here the user can only see active projects which he owns. See ControllerAdditions#conditions for a way to use this in database queries.
If the conditions hash does not give you enough control over defining abilities, you can use a block to write any Ruby code you want.
can :update, Project do |project|
project && project.groups.include?(user.group)
end
If the block returns true then the user has that :update ability for that project, otherwise he will be denied access. It’s possible for the passed in model to be nil if one isn’t specified, so be sure to take that into consideration.
The downside to using a block is that it cannot be used to generate conditions for database queries.
You can pass :all to reference every type of object. In this case the object type will be passed into the block as well (just in case object is nil).
can :read, :all do |object_class, object|
object_class != Order
end
Here the user has permission to read all objects except orders.
You can also pass :manage as the action which will match any action. In this case the action is passed to the block.
can :manage, Comment do |action, comment|
action != :destroy
end
You can pass custom objects into this “can” method, this is usually done through a symbol and is useful if a class isn’t available to define permissions on.
can :read, :stats
can? :read, :stats # => true
119 120 121 122 |
# File 'lib/cancan/ability.rb', line 119 def can(action, subject, conditions = nil, &block) @can_definitions ||= [] @can_definitions << [true, action, subject, conditions, block] end |
#can?(action, subject, *extra_args) ⇒ Boolean
Use to check the user’s permission for a given action and object.
can? :destroy, @project
You can also pass the class instead of an instance (if you don’t have one handy).
can? :create, Project
Any additional arguments will be passed into the “can” block definition. This can be used to pass more information about the user’s request for example.
can? :create, Project, request.remote_ip
can :create Project do |project, remote_ip|
# ...
end
Not only can you use the can? method in the controller and view (see ControllerAdditions), but you can also call it directly on an ability instance.
ability.can? :destroy, @project
This makes testing a user’s abilities very easy.
def test "user can only destroy projects which he owns"
user = User.new
ability = Ability.new(user)
assert ability.can?(:destroy, Project.new(:user => user))
assert ability.cannot?(:destroy, Project.new)
end
50 51 52 53 54 55 56 |
# File 'lib/cancan/ability.rb', line 50 def can?(action, subject, *extra_args) matching_can_definition(action, subject) do |base_behavior, defined_actions, defined_subjects, defined_conditions, defined_block| result = can_perform_action?(action, subject, defined_actions, defined_subjects, defined_conditions, defined_block, extra_args) return base_behavior ? result : !result end false end |
#cannot(action, subject, conditions = nil, &block) ⇒ Object
Define an ability which cannot be done. Accepts the same arguments as “can”.
can :read, :all
cannot :read, Comment
A block can be passed just like “can”, however if the logic is complex it is recommended to use the “can” method.
cannot :read, Product do |product|
product.invisible?
end
136 137 138 139 |
# File 'lib/cancan/ability.rb', line 136 def cannot(action, subject, conditions = nil, &block) @can_definitions ||= [] @can_definitions << [false, action, subject, conditions, block] end |
#cannot?(*args) ⇒ Boolean
Convenience method which works the same as “can?” but returns the opposite value.
cannot? :destroy, @project
62 63 64 |
# File 'lib/cancan/ability.rb', line 62 def cannot?(*args) !can?(*args) end |
#clear_aliased_actions ⇒ Object
Removes previously aliased actions including the defaults.
182 183 184 |
# File 'lib/cancan/ability.rb', line 182 def clear_aliased_actions @aliased_actions = {} end |
#conditions(action, subject) ⇒ Object
Returns a hash of conditions which match the given ability. This is useful if you need to generate a database query based on the current ability.
can :read, Article, :visible => true
conditions :read, Article # returns { :visible => true }
Normally you will not call this method directly, but instead go through ActiveRecordAdditions#accessible_by method.
If the ability is not defined then false is returned so be sure to take that into consideration. If the ability is defined using a block then this will raise an exception since a hash of conditions cannot be determined from that.
197 198 199 200 201 202 203 |
# File 'lib/cancan/ability.rb', line 197 def conditions(action, subject) matching_can_definition(action, subject) do |base_behavior, defined_actions, defined_subjects, defined_conditions, defined_block| raise Error, "Cannot determine ability conditions from block for #{action.inspect} #{subject.inspect}" if defined_block return defined_conditions || {} end false end |