Skip to content
This repository has been archived by the owner on Dec 12, 2021. It is now read-only.

Authorization failing on uncountable resource #193

Closed
jgadbois opened this issue Nov 12, 2010 · 10 comments
Closed

Authorization failing on uncountable resource #193

jgadbois opened this issue Nov 12, 2010 · 10 comments

Comments

@jgadbois
Copy link

I have a resource called Equipment. It's set up as uncountable in the inflector.

Even if I give a user :manage, Equipment capability, he still gets an access denied error.

The only exception is the admin who has :manage, All capability. This happens on two different models that are uncountable. All other models are working fine.

I'm using Rails 3.0 and CanCan 1.4.0

@ryanb
Copy link
Owner

ryanb commented Nov 12, 2010

Are you doing load_and_authorize_resource? If so, what is the name of the controller you're doing this on?

@jgadbois
Copy link
Author

Yes I was doing load_and_authorize_resource on EquipmentController (equipment_controller.rb)

@ryanb
Copy link
Owner

ryanb commented Nov 12, 2010

Hmm, I'm not certain why this is not working. It will call params[:controller].singularize to determine the name of the resource which should be "equipment" here, and that's correct.

I can't tell what's wrong without knowing more about the model that it's passing to the authorization check. Try adding this to your ApplicationController so you can get more information about the model that it's denying access on.

rescue_from CanCan::AccessDenied do |exception|
  logger.debug "Access denied on #{exception.action} #{exception.subject.inspect}"
  # ...
end

@jgadbois
Copy link
Author

Here's my output...this one is on a uncountable Faq model (FaqController).
ability.rb has can :manage, Faq for any user. Not sure if the output is very helpful.

Access denied! index [#<Faq id: 1, title: "Why can't I do this?", content: "

\r\n\tTETASDFASDFASDF

\r\n", created_at: "2010-11-12 20:58:43", updated_at: "2010-11-12 20:58:43">, #<Faq id: 2, title: "asfas", content: "

\r\n\tdfasdfadfsadf

\r\n", created_at: "2010-11-12 21:38:59", updated_at: "2010-11-12 21:38:59">]

@ryanb
Copy link
Owner

ryanb commented Nov 14, 2010

Oh, it's passing an array to the authorize! check. It's doing this because the index action sets the @faq array and then the authorization filter thinks this is a single model and attempts to do the check through that.

I guess the best solution is to check in the authorization to see if the instance variable is an array and if so don't perform the authorization.

@ghost
Copy link

ghost commented Nov 21, 2010

I just encountered the same problem. Funny enough using an "Equipment" resource.

I traced it down to ability.rb > relevant_can_definitions().

When it does the can_definition.relevant? call, the action is :index and the subject is an ActiveRecord::Relation instance. Subject happens to have the class.name of "Equipment". Doing the same call passing in an Equipment class and it passes. With the ActiveRecord::Relation instance the "relevant?" call returns false.

Using Rails 3, Ruby 1.8.7, CanCan 1.4.1

Any progress being made on this?

@ryanb
Copy link
Owner

ryanb commented Nov 22, 2010

I haven't had a chance to work on it yet. Feel free to fork and submit a pull request. Basically we just want to check if @equipment looks like an array in the controller level, and if so don't pass it to the authenticate! check.

@ryanb
Copy link
Owner

ryanb commented Nov 22, 2010

For a temporary work-around in your application, it's best to do the authorization manually.

load_resource

def index
  authorize! :index, Equipment
  # ...
end

@ryanb
Copy link
Owner

ryanb commented Jan 5, 2011

don't authorize uncountable instance in collection action - closed by bc9ecb2

@hisenb3rg
Copy link

Oh thats great!

I've just bumped into this issue and wanted to file/fix a bug, and now I see you did it yesterday. Awesome :) Keep up the great work, I really enjoy using cancan!

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants