#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: closed
Component: contrib.auth | Version: 2.0
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Mehmet Dogan):
* status: new => closed
* resolution: => duplicate
Old description:
> 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.
New description:
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:8>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.6cb538fcbace0ce77ea83dce6b5ca530%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
