#20218: Default authorization backend returns False when queried for object
level
permissions
------------------------------+------------------------------------
Reporter: soren@… | Owner: nobody
Type: Bug | Status: new
Component: contrib.auth | Version: 1.5
Severity: Normal | Resolution:
Keywords: auth | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by Mehmet Dogan):
Being unaware of this ticket, I had opened another (should have checked!).
Here it is:
Long story here: https://github.com/django-guardian/django-
guardian/issues/49
Short story: 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
user.has_perm('foo.change_bar'):
...
}}}
However, this not only looks ugly, but also requires polling of all the
backends twice, and thus, is a performance loss.
First, and possibly the best, solution to this is that, django does not
deny permission if obj argument is provided, but just ignores it. This is
also very logical, one who has a permission for the entire model/table,
would also have it for an instance/row. This way by properly ordering
backends in the settings, it could be a fallback solution for the lower
level checkers. This might be the move in the right direction, although it
is backwards incompatible.
A second solution is a keyword argument, such as `fallback_to_model=None`,
that will allow lower-level checkers mimic the model level permissions
that django does. Obviously, this is not DRY. But is needed if the first
solution is not accepted to get the necessary permissions with one round
of polling, and without cluttering the code. If it was accepted, it would
still be a useful addition since it would allow backends to prefer to
handle the fallback by themselves. Or, it would allow users who fallback
by default override that behavior and not fallback (via a value of
`False`), i.e., when object level permissions are definitive.
--
Ticket URL: <https://code.djangoproject.com/ticket/20218#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/075.ebad4be13187c0ece916eb18ba6e37a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
