You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I notice you only support anonymous (ie nil current_user, which is what devise provides when there is no user logged in) users through overriding can_xx behaviors on the controller. Although it ruins some of the elegance of the code, if you essentially duplicate the user's can_xx in the enforcer's can_xx, it would be possible to describe anonymous user permissions in the model, which would be really nice (ie, I could deal with nil values on a case by case basis in the model). For most of my use cases, I'm thinking I'm going to want permissions for anon, 'regular', and admin users -- in order to do that right now, I'll need to essentially dupe the model permissions in the controller to avoid nil errors. More than willing to submit code with tests if this is something you would consider merging, but if this isn't the direction you want to go in, I'll probably just go with a monkey patch. My implementation would probably just dupe the user can_xx into the enforcer can_xx, which again, isn't pretty, but should have the desired effect of passing the current user down into the resource even if they're nil. I guess this could be surprising if people have overridden the can_xx on the user model, but right now I can think of very few reasons to do that, unless you wanted to create a user that's forbidden entirely from some kind of action.
Eager to hear if you have encountered this problem and solved it in a different way (null user pattern as opposed to a nil value?).
Thanks for the library, btw -- nice and succinct. I like it.
EDIT: I think we can workaround the problem of providing expected behavior when overriding user can_xx by checking to see if the current user exists and if it responds to the method. Implemented below in the monkey patch. Yes, this further sullies the code, but again, gets me the behavior I want. If you wanted to pretty it up, I guess you could create a class method that both the enforcer can_xx and the user can_xx share.
The text was updated successfully, but these errors were encountered:
I notice you only support anonymous (ie nil current_user, which is what devise provides when there is no user logged in) users through overriding can_xx behaviors on the controller. Although it ruins some of the elegance of the code, if you essentially duplicate the user's can_xx in the enforcer's can_xx, it would be possible to describe anonymous user permissions in the model, which would be really nice (ie, I could deal with nil values on a case by case basis in the model). For most of my use cases, I'm thinking I'm going to want permissions for anon, 'regular', and admin users -- in order to do that right now, I'll need to essentially dupe the model permissions in the controller to avoid nil errors. More than willing to submit code with tests if this is something you would consider merging, but if this isn't the direction you want to go in, I'll probably just go with a monkey patch. My implementation would probably just dupe the user can_xx into the enforcer can_xx, which again, isn't pretty, but should have the desired effect of passing the current user down into the resource even if they're nil. I guess this could be surprising if people have overridden the can_xx on the user model, but right now I can think of very few reasons to do that, unless you wanted to create a user that's forbidden entirely from some kind of action.
Eager to hear if you have encountered this problem and solved it in a different way (null user pattern as opposed to a nil value?).
Thanks for the library, btw -- nice and succinct. I like it.
EDIT: I think we can workaround the problem of providing expected behavior when overriding user can_xx by checking to see if the current user exists and if it responds to the method. Implemented below in the monkey patch. Yes, this further sullies the code, but again, gets me the behavior I want. If you wanted to pretty it up, I guess you could create a class method that both the enforcer can_xx and the user can_xx share.
The text was updated successfully, but these errors were encountered: