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.

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

RE: Default Authorization BackEnd Denying Permissions ifObjectProvided

Or, extend ModelBackend to override the object-denying behavior, and provided that as an option. Am I getting you right? Seems like options for changing the global behavior is growing. However, I still think there is need for local override. Otherwise, re-usable apps will have to adopt either

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

Carlton, First, thanks for stirring the conversation. Can you give an example of what you mean by option 3. The comment you linked did not have much detail. Thanks, From: Carlton Gibson Sent: Wednesday, January 17, 2018 4:45 AM To: Django developers (Contributions to Django itself) Subject:

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

Hi. @Andrew: I'll look at your post anon, as it's longer. On Wednesday, 17 January 2018 20:46:27 UTC+1, Mehmet Dogan wrote: > > Can you give an example of what you mean by option 3. > Well, I don't a concrete suggestion in mind, but the general idea would be to have ModelBackend proxy to

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

Although I found it very interesting at first, this looks dangerous since it changes how the API work for all apps installed. Example, guardian makes calls to user.has_perm(perm) in several places to check model permissions. Although periphery features, they would be broken. From: Florian

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

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 ObjectProvided

Yea :) I just figured that after a few emails. I am learning a lot! On Wed, Jan 17, 2018 at 3:39 PM Florian Apolloner wrote: > > > On Wednesday, January 17, 2018 at 9:04:30 PM UTC+1, Mehmet Dogan wrote: >> >> Although I found it very interesting at first, this looks

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

On Wednesday, January 17, 2018 at 9:04:30 PM UTC+1, Mehmet Dogan wrote: > > Although I found it very interesting at first, this looks dangerous since > it changes how the API work for all apps installed. Example, guardian makes > calls to user.has_perm(perm) in several places to check model

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

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

Re: Ticket #29015

Hello ! I have made a simple change to the django/db/backends/postgresql/base.py and added a NotSupportedError for the database-name. The result of the makemigrations command currently looks like this: Traceback (most recent call last): File "manage.py", line 15, in

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

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

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

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