Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Carlton Gibson]

Hi Mehmet

On Tuesday, 23 January 2018 15:05:06 UTC+1, Mehmet Dogan wrote:
>
> Do you think what Florian or I sent is a good example to include in the 
> docs for the way #1?
>

Yes.

I was just looking for where. Candidates: 

* https://docs.djangoproject.com/en/2.0/topics/auth/default/#topic-authorization
* 
https://docs.djangoproject.com/en/2.0/ref/contrib/auth/#django.contrib.auth.models.User.has_perm
* 
https://docs.djangoproject.com/en/dev/topics/auth/customizing/#handling-authorization-in-custom-backends

None of these are quite right. (Although top one is favourite. The last one 
has this line: "If you wish to provide custom behavior for only part of the 
backend API, you can take advantage of Python inheritance and subclass 
ModelBackend instead of implementing the complete API in a custom 
backend..." — which is about as close as we get.)

There's also this discussion: 

* https://code.djangoproject.com/wiki/RowLevelPermissions

Looking at this, I don't think we're quite saying what I took us to be 
saying. i.e. we're not clearly spelling out the object-permissions 
situation. 
(Beyond those pages all the top search results are from DRF, and Django 
Guardian, which must be where people are picking up this knowledge.)

As such, if you wanted to work on a docs focused PR here I'd be happy to 
review and input on that on GitHub. 
(I take it this would say a bit more than currently on how User.has_perms() 
proxies to the backends, such that some may handle object-level 
permissions.)

Thanks for the effort! 

Kind Regards,

Carlton

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/684dc59f-ba6f-44b0-9da3-59b1dad06062%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Mehmet Dogan]

Thanks for the response. Do you think what Florian or I sent is a good example 
to include in the docs for the way #1?

From: Carlton Gibson
Sent: Monday, January 22, 2018 2:13 AM
To: Django developers (Contributions to Django itself)
Subject: Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

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...

I've used this API, with Django Guardian and without. It never occurred to me 
that there was a problem with ModelBackend's behaviour. 

For me the it (i.e. the docs) says:

> I don't do object permissions so I always return `False` if you ask. 

That seems clear, safe, and unambiguous. 

I see users read the API as hierarchical. Having thought about this issue,
ultimately, I think it's a misunderstanding (and so a docs issue).

I come back to Florian's point about what the right API should be? 

`user.has_perm("for.change_bar", obj=some_bar)`

What are we offering here? 
The ability to cycle through a number of backends checking permissions, **plus**
a (moderately) simple default permissions system. That's it. 
(We're not offering the most full-featured ACL-powered goodness. That's 
deliberate.)

Is this a good API for that? I think probably yes. 

Short of looking at ≈all the major frameworks out there and seeing what they 
offer instead, I don't see a ground for change. Not currently. 

I do see two ways forward: 

* A possible change to the docs: highlight what we're doing (again) 
  — provide the example of an alternate backend, with the other behaviour. 
  
* Possible backwards compatible refactoring of the authentication and 
authorization 
  roles of the authentication backends. Right now we have a class with two 
  responsibilities, so splitting that may make sense. (It may make future steps 
  clearer.) I think that would need to be done piecemeal and in PRs, with tests 
  and docs etc to be sensibly assessed. (It's impossible to assess code on the 
  mailing list, at least for me.)
  
Given the scope of the permissions system, I'm not convinced we need to make an 
actual code change here. (i.e. I'm not convinced about need for the second 
refactoring part.) The goal is to provide a simple but extensible system. We 
have that. I don't see any limitation that can't be worked around in user code 
if it doesn't suit. 

For me, I'd close as won't fix.
https://code.djangoproject.com/ticket/20218

Kind Regards,

Carlton




-- 
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/MLWfvPPVwDk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fb3ac66-8d78-4393-b3ca-83cba330bccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a6740fd.f8429d0a.f1b4e.0c3c%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Mehmet Dogan]

Andrew,

> Why you would use the user API if you cared about a specific backend?

True. I wouldn’t. 

> Using your example of the RolesBackend, either 
> A) You want to leave it up to the user whether a role grants object level 
> permissions or not.
> B) You want to have consistent behavior for your backend. 

Seemed like I wanted consistent behavior without relying on any particular 
backend. But, I see this restricts the design choices elsewhere or for others. 
Whether advantages outweigh disadvantages, or vice versa, I am not sure. 

I was envisioning that one who uses multiple backends, say at least 3, would 
get everything needed through the common API, as well as seamless reusability 
of backends within each other. 

But your scenario B gave me some ideas for backup. Thanks 

Mehmet

From: Andrew Standley
Sent: Thursday, January 18, 2018 1:29 PM
To: django-developers@googlegroups.com
Subject: Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

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, either 
A) You want to leave it up to the user whether a role grants object level 
permissions or not.
B) You want to have consistent behavior for your backend. 

Explanation:

A) In this case you would use your pseudo code example. 
To return true (proposed) for an object when a user has the model level 
permission (ie a role with this permission) the user would configure their 
setting so
```
AUTHENTICATION_BACKENDS = [
    'PermissionAuthorizationBackend',
    'RolesBackend',
]
```
To return false (current) for an object when a user has the model level 
permission the user would configure their setting so
```
AUTHENTICATION_BACKENDS = [
    'ModelOnlyPermissionAuthorizationBackend',
    'RolesBackend',
]
```
In either case the backend order does not particularly matter for this example.

B) In this case the backend should derive or call the backend whose behaviour 
it requires.
```
class RolesBackend(PermissionAuthorizationBackend):
    def has_perm(self, user_obj, perm, obj=None):
    ...
    for delegate in delegates:
  if super(RolesBackend, self).has_perm(user_obj, perm, obj):
  return True
   return False
```

Cheers,
    Andrew

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a60fdc2.c91b9d0a.50b0.7583%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Mehmet Dogan]

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 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.
>>
>
> Funny that you would say that, because your proposed setting
> OBJECT_PERMISSION_FALLBACK_TO_MODEL does exactly the same thing ;)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/MLWfvPPVwDk/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6f2b5df3-84dd-4bc2-b945-4cc80a838372%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFdefwOmrFG7HocZsgq76-GDknGenjagp%2BfqCFmc5WN6stG1HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Florian Apolloner]

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 permissions. 
> Although periphery features, they would be broken.
>

Funny that you would say that, because your proposed setting 
OBJECT_PERMISSION_FALLBACK_TO_MODEL does exactly the same thing ;)

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f2b5df3-84dd-4bc2-b945-4cc80a838372%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Carlton Gibson]

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 another class (a Strategy ?) that did the 
actual permission check. 

We'd then have (at least) two versions: one with the current 
implementation, and one with the alternative. 

Exactly how the user would configure which version to use (etc) would need 
thinking about. 

The question is whether it's worth the price of admission, vs just, say, 
subclassing ModelBackend. 

C.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fc4b4544-dd15-4672-8a5b-27e9bcb7d4a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Mehmet Dogan]

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 Apolloner
Sent: Wednesday, January 17, 2018 12:45 PM
To: Django developers (Contributions to Django itself)
Subject: Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

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 this should do it. 
-- 
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/MLWfvPPVwDk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ff0142a5-cca0-4d8c-8497-b988b04ba4ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a5fac41.1b5b9d0a.5a28c.069e%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Mehmet Dogan]

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 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-standing behaviour, this is considered _unexpected_.

Ticket is: https://code.djangoproject.com/ticket/20218

There are two related tickets regarding permission-checking in the Admin:

* https://code.djangoproject.com/ticket/13539
* https://code.djangoproject.com/ticket/11383

Currently, I see three options:

1. Close as "Won't Fix", perhaps with a review of the documentation to see if we
   can't clarify/emphasise the behaviour somewhere.

    This is the path of least resistance. It conforms to the original design
    decision. It preserves the long-standing behaviour. (Whilst, yes, some find 
the
    behaviour unexpected, it has a sense; it just depends how you look at it.)

    The objection is to this kind of check:

        if user.has_perm('foo.change_bar', obj=bar) or 
user.has_perm('foo.change_bar'):
            ...

    * Whilst, granted, it's a little clumsy, there's no reason this couldn't be
      wrapped in a utility function. (There's a suggestion to that effect on the
      Django-Guardian issue tracker[^1]. This seems like a good idea, simple 
enough
      to live in user code.)
    * `ModelBackend` permission lookups are cached[^2] so the performance worry
      here should be negligible.

2. Implement the (straight) backwards incompatible change.

    The difficulty here is (we guess) why this ticket has been open so long.

    If we are convinced this is the right way to go — i.e. that the current
    behaviour is in fact **wrong** — then we should go ahead despite the
    difficulty.

    Working out what that entails is non-trivial. That's why it needs a decent
    discussion and consensus here.

    Which leads to...

3. Break out the permissions aspect of `ModelBackend` in order to make it 
   pluggable in some way. Then allow users to opt-in to a new version with the 
   adjusted behaviour.
   
   There is some discussion of this on one of the related tickets[^3].
   
   Again, exactly what the migration path is needs some planning. 

I'm not sure what the correct answer is. 

[^1]: https://github.com/django-guardian/django-guardian/issues/459
[^2]: 
https://docs.djangoproject.com/en/2.0/topics/auth/default/#permission-caching
[^3]: f.f. https://code.djangoproject.com/ticket/13539#comment:16


Kind Regards,

Carlton

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/django-developers/MLWfvPPVwDk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cab981b8-7dc7-4e9d-9dcc-442b36820cdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a5fa805.0543ca0a.cde47.dde6%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.