Opened 7 years ago
Last modified 7 years ago
#29012 closed Uncategorized
Coordination of Authorization Backends in Permission Checking — at Initial Version
Reported by: | Mehmet Dogan | Owned by: | nobody |
---|---|---|---|
Component: | contrib.auth | Version: | 2.0 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
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) and 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 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=False, that will allow lower-level checkers mimic the model level permissions that django does. Although this looks not DRY at first, it would give other backends more control whether to fallback to django or not (in case first solution is also accepted of course, otherwise, this is needed to get the necessary permissions with one round of polling).