chaps-io / access-granted

Multi-role and whitelist based authorization gem for Rails (and not only Rails!)
MIT License
773 stars 41 forks source link

Permissions with blocks work too persmissive (block is ignored) #24

Closed vittorius closed 8 years ago

vittorius commented 8 years ago

Hello.

I have such policy:

can [:read, :update, :destroy], User do |user, merchant_admin|
  user.merchant.present? && created_user_is_of_creator_merchant?(merchant_admin, user)
end

and check

<% if can? :read, User %>
  <li><%= link_to 'Users', users_path %></li>
<% end %>

When I add byebug to policy block the execution even doesn't get stopped. So, looks like it looks at User at decides that it's enough.

Only when I comment out the policy definition, the check works.

vittorius commented 8 years ago

Update: looks like block works only when checking the User instances. But why would such definition permit any operation on class?

noorhammad commented 8 years ago

@vittorius can you document the solution you used to get the block to execute?

vittorius commented 8 years ago

It's a dumb hack )

<% if current_user.has_privileges?(:admin) %>

(has_privileges? is just my method for model User which checks the it's in appropriate role)

pokonski commented 8 years ago

@vittorius

Update: looks like block works only when checking the User instances. But why would such definition permit any operation on class?

you are not meant to use :destroy or :update on classes. Because it doesn't make sense, you can't remove or update a class.

So the only permission you usually need to check on a class is :create.

If you want to allow someone to view users, specify the can :read, User separately from :update and :create