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
Global permissions vs object permissions #380
Comments
Yes to this! permission_required_or_403 has the accept_global_perms parameter, but there's no way in a view to do the same thing with get_obj_perms I propose a get_obj_perms_with_global tag which includes global perms. I don't know if you've already started down this road, but I'll start working up a patch to do it; if you've already made a start feel free to stop me :) P.S. I think there's an argument to be made that the default behaviour should be to include global permissions, it seems to me that when you ask "can user X do Y to object Z" that implies checking all of user/object, group/object, user/global, group/global permissions. But that might just be because of the the way I use it. |
Having said all that, it is pretty straight forward to check global permissions separately...Hrmmm. |
Pesticles: there's enough issues on guardian as testament to how confusing this is. We get bit by it every six months ... if request.user.has_access('foo', obj) should be true if they have global permissions but not object level permissions. Writing the check twice is yucky. What needs to happen to get this changed? |
I think somebody needs to write a pull request... Ideally in such a way that it doesn't break existing code (if this is sane and feasible or not I don't know). |
Old issue, but I don't see a pull request yet. Any news on this one? I'm running into the same behavior, which I think is not very predictable. Thanks a bunch! |
I added some comments to #49 since that had more insight on the issue of whether and how to fallback to globals when object level fails. I am not sure if closed issues raise notification, so I am adding this here. |
Depending on the design decisions being made I have intent to work on some of these issues. |
I would be happy to help with these issues. |
#327 seems fixed to me.
|
On #155: Addition of the following two lines is requested to
to exclude the Model's default permissions. First, I am not clear on how But, while looking into that, I noticed there needs to be a separation of object vs model permissions in:
It seems like, it is saving at the object level whatever permission is missing, while in my opinion, any permission available at the model level should be skipped, or an option to that end be provided. |
I think a global setting such as |
+1 for GUARDIAN_FALLBACK_TO_MODEL. Per the discussion on #49 I think that setting might would also work well to control whether the ObjectPermissionBackend was explicit or not. |
I created a pull request (#546). It allows checker functions in core.py option to fallback to (or include) model level permissions. Other modules also need to be reviewed. I plan on reviewing them as I use them. If anyone would like to jump in, most welcome. |
Global permissions are still not respected for object level permission if set, am I wrong here? u = User.objects.get(id=1)
c = Client.objects.get(id=1)
assign_perm('core.change_client', u)
u = User.objects.get(id=1) # reloading user for perm refresh
u.has_perm('core.change_client') # True
u.has_perm('core.change_client', c) # False
u.has_perm('change_client', c) # False
get_perms(u, c) # [] And what does setting |
Wouldn't it be sufficient to add this to
def get_user_perms(self, obj):
# ....
user_global_perms = Permission.objects.filter(content_type=ctype)\
.filter(user=self.user)\
.values_list('codename', flat=True)
user_object_perms = user_perms_qs.values_list("codename", flat=True)
user_perms = list(chain(user_global_perms, user_object_perms))
return user_perms |
There seems to be a number of bugs due to some routines using global permissions, and others only using object permissions. Will close the related bugs and reference them here.
The text was updated successfully, but these errors were encountered: