Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hi Mehmet, Sorry for the slow reply. I didn't have capacity to return to this last week. > Hey Carlton ... What do you say? Well, my first thought is that I don't see any great consensus for a change here. I don't see it as **my** decision to make. This has been open a while, however, so..

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Aymeric, If one doesn’t have time to read 21 emails, then should also not have time to judge them. Regards, On Fri, Jan 19, 2018 at 2:33 PM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > 2018-01-19 17:54 GMT+01:00 Mehmet Dogan : > >> I propose throwing out the proposed behavior

Re: Default Authorization BackEnd Denying Permissions if Object Provided

2018-01-19 17:54 GMT+01:00 Mehmet Dogan : > I propose throwing out the proposed behavior as Option B, and see what > happens. > "Make changes and see what happens" doesn't sound like the way Django is maintained in general. Unfortunately I don't have enough motivation to go through the 21 emails

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hey Carlton, I think everybody said what they would. What do you say? I propose throwing out the proposed behavior as Option B, and see what happens. Something along these lines: *class *ModelBackendIgnoreObject(ModelBackend): *def *get_user_permissions(self, user_obj, obj=*Non

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hey Mehmet, If a backend relies on PermissionAuthorizationBackend, and another require the ModelOnlyPermissionAuthorizationBackend     So I think this is the point that confuses me. Why you would use the user API if you cared about a specific backend? Using your example of the RolesBackend, e

Re: Default Authorization BackEnd Denying Permissions if Object Provided

For the migration, I think most sensible way is to *extend *the current backend and provide it as an option, until the other is depreciated and removed. This would act as a global setting in the meantime. But eventually, I think, we should have just 1 default backend for the sake of consistency ove

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Andrew, Yes, I think we can safely assume *apps *would be backend agnostic. I was actually referring to the *backends *themselves, if they use user.has_perm(...). This might sound counter-intuitive at first but I think it is possible, and actually I am working on one right now (see my long answer

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Thursday, January 18, 2018 at 2:55:27 AM UTC+1, Mehmet Dogan wrote: > > If that is the way forward, I will volunteer for the code. But, as you > also point out, there needs to be a *path* out. That I don't know :) > Personally I think it is (though I haven't had hours to think about it). Th

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Mehmet,     Can you explain to me what the situation would be that an app could simply not be backend agnostic? Given that AUTHENTICATION_BACKENDS is a /user/ configuration, it seems odd that an app would ever design around specific backends being installed. I'm not sure I follow your logic on

Re: Default Authorization BackEnd Denying Permissions if Object Provided

The "expected behavior" is that *one has permission on an entire table would also have permission on a row of it*. This seems to be the one thing that everyone can agree on. And, I am yet to see a person that argues otherwise. But, it seems, we just need someone or some people to make that *hard *d

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Andrew, Thank you for the input. Having options is good. My concern about that is, it may divide the already small backends population. If a backend relies on PermissionAuthorizationBackend, and another require the ModelOnlyPermissionAuthorizationBackend; then one cannot use both. Guardian, at its

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Wednesday, January 17, 2018 at 7:58:17 PM UTC+1, Carlton Gibson wrote: > > Given your comment, would it be along the lines of "Close as "Won't Fix", > perhaps with a review of the documentation", to point users to subclassing > ModelBackend if they need the alternate behaviour? > My comment

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hi Florian, I was hoping you'd post. You've been active on the entire (very-long) history of this issue. Can I ask for your take? Given your comment, would it be along the lines of "Close as "Won't Fix", perhaps with a review of the documentation", to point users to subclassing ModelBacken

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hi Carlton,     Thanks for the thoughts. I just wanted to share my opinion on your options. 1. "Won't Fix"     I have yet to find anywhere the original design decisions were documented. Based on what I can find, it appears that object level permissions where a bit of an after-though for the i

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Wednesday, January 17, 2018 at 5:48:03 PM UTC+1, Mehmet Dogan wrote: > > Florian, > > Can you clarify this part, I am not sure what you meant: > class MyBackend(ModelBackend): def has_perm(…, obj=None,…): if obj: obj = None return super().has_perm(…) something along the lines of

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Florian, Can you clarify this part, I am not sure what you meant: > in the worst case the user would have to change the permission backend which is easy enough… On Wed, Jan 17, 2018 at 10:31 AM Florian Apolloner wrote: > > > On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson w

Re: Default Authorization BackEnd Denying Permissions if Object Provided

On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson wrote: > > The objection is to this kind of check: > > if user.has_perm('foo.change_bar', obj=bar) or > user.has_perm('foo.change_bar'): > ... > FWIW I would never write code like this. `user.has_perm('

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Hi Mehmet, Due to the BC issues, this is fairly in-depth. Having looked at the history, here are my initial thoughts. The initial issue here is this behaviour from `ModelBackend`: ``` user.has_perm('foo.change_bar', obj) False user.has_perm('for.change_bar') True ``` Although the long-sta

Re: Default Authorization BackEnd Denying Permissions if Object Provided

I updated my patch: https://github.com/django/django/pull/9581 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-dev

Re: Default Authorization BackEnd Denying Permissions if Object Provided

And I forgot; 3rd advantage: - The 3 backend methods mentioned above won't have to take an extra kwarg such as fallback_to_model; thus backward compatible there. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django its

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Seems like I found a better keyword argument than fallback_to_model. For the following backends setting: AUTHENTICATION_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', 'guardian.backends.ObjectBackend', 'roles.backends.RoleBackend', ) And the ways to check: user.has_pe

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Created a pull request: https://github.com/django/django/pull/9581 Mehmet -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Based on this patch: the following 3 methods in the custom authorization backends will have to admit a *fallback_to_model *keyword argument: *def *has_perm(self, user_obj, perm, obj=None, fallback_to_model=None) def get_group_permissions(self, user_obj, obj=None, fallback_to_model=None) def ge

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Here is a sample patch: https://github.com/doganmeh/django/commit/d85cd3a530984ab5e4cb42f93629a64eb0b65b07 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving

Re: Default Authorization BackEnd Denying Permissions if Object Provided

And the other: Here is what I propose in terms of working around the backward compatibility that seems to have kept it from being solved for so long. 1) define a global setting, say: OBJECT_PERMISSION_FALLBACK_TO_MODEL=False. This is to help maintain the default behavior (unless the setting i

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Here is the text of linked stuff for convenience: For authorization backends checking object level permissions (like guardian) usually requires calling the django's default authorization backend as a fallback to the more general set of permissions: if user.has_perm('foo.change_bar', obj=bar) or

Default Authorization BackEnd Denying Permissions if Object Provided

Hello all, I had opened a ticket re issue noted in subject, which happened to be a duplicate, anyways, the text is here : Tim Graham told that it needs to be discussed here. Seems this is a long going issue, with several related issues (se