-
-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change in rules behaviour affects RailsAdmin root actions #413
Comments
can you please provide a test that shows the expected behaviour and what actually happens? You can use this gist: https://gist.github.com/coorasse/3f00f536563249125a37e15a1652648c I see that the subjects are now |
Sure, I could write out a test, but would the test be from the RailsAdmin perspective specifically? Basically the behaviour is exactly what you describe where subjects are At any rate, I can write out the tests, although perhaps a backtrace with method arguments from RailsAdmin might also be useful as well? What it basically boils down to is that RailsAdmin is asking |
I think this is a specific case for RailsAdmin. I don't see documented anywhere else the usage of |
I just added a test for you situation. I think the usage of cancancan here is wrong, or at least, not officially supported. The correct thing to do would be define |
This issue should be reported to @mshibuya |
I think cancancan2 needs a new adapter for RailsAdmin. Until then you can us the following: module RailsAdmin
module Extensions
module CanCanCan2
class AuthorizationAdapter < RailsAdmin::Extensions::CanCanCan::AuthorizationAdapter
def authorize(action, abstract_model = nil, model_object = nil)
return unless action
reaction, subject = fetch_action_and_subject(action, abstract_model, model_object)
@controller.current_ability.authorize!(reaction, subject)
end
def authorized?(action, abstract_model = nil, model_object = nil)
return unless action
reaction, subject = fetch_action_and_subject(action, abstract_model, model_object)
@controller.current_ability.can?(reaction, subject)
end
def fetch_action_and_subject(action, abstract_model, model_object)
reaction = action
subject = model_object || abstract_model&.model
unless subject
subject = reaction
reaction = :read
end
return reaction, subject
end
end
end
end
end
RailsAdmin.add_extension(:cancancan2, RailsAdmin::Extensions::CanCanCan2, authorization: true) and then: RailsAdmin.config do |config|
config.authorize_with :cancancan2
end and finally change |
Since the issue is related to an incorrect usage of cancancan from rails_admin and in this issue there is a solution provided I'm going to close it. |
I am not saying this is right approach; however, it solved the issue for now until the change happened.
|
I think we need to have a link to this issue in readme. It is hard to find it. |
I see task #402 about "we want to remove You said that this is intended, but it is not. You just matched change with Reduce unnecessary allocations in Rule creation. We need to have explicit exception if subject is nil. |
Updated docs on RailsAdmin (https://github.com/sferik/rails_admin/wiki/CanCanCan). For the explicit exception I agree. PR is welcome 👍 |
The change in c81cf44 to
Cancan::Rule#initialize
has introduced a small behavioural change that is affecting any authorization calls involving anil
subject. This was discovered using a custom RailsAdmin action that is root-level and thus has no real subject. In these cases, the calls to#can?
have an action but just anil
subject.The main difference in the behaviour can be seen in how the
@subjects
value is initialized when thesubject
argument isnil
:Because the
@subjects
value is an empty array as opposed to an array with a singlenil
element, none of the rules that would normally match against it are matching.Perhaps the following would suffice as an easy patch?
The text was updated successfully, but these errors were encountered: