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.
