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 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/1fb3ac66-8d78-4393-b3ca-83cba330bccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
