[Django] #29012: Coordination of Authorization Backends in Permission Checking
Django
-----------------------------------------+------------------------
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/29012>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mehmet Dogan:
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) 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).
New 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 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).
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:1>
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mehmet Dogan:
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
> 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).
New 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 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. If the first solution is not accepted, this is needed to
get the necessary permissions with one round of polling. Otherwise, it
seems like it is still a useful addition since it would allow backends to
prefer to handle the fallback by themselves.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:2>
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mehmet Dogan:
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
> 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. If the first solution is not accepted, this is needed
> to get the necessary permissions with one round of polling. Otherwise, it
> seems like it is still a useful addition since it would allow backends to
> prefer to handle the fallback by themselves.
New 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 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. If the first solution is not accepted, this is needed to
get the necessary permissions with one round of polling (and without
cluttering the code). 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., object level permissions are
definitive.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:3>
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mehmet Dogan:
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
> 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. If the first solution is not
> accepted, this is needed to get the necessary permissions with one round
> of polling (and without cluttering the code). 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., object
> level permissions are definitive.
New 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 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., object level permissions are definitive.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:4>
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mehmet Dogan:
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
> 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., object level permissions are
> definitive.
New 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 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/29012#comment:5>
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mehmet Dogan:
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
> 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:
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/29012#comment:6>
Django
Reporter: Mehmet Dogan | Owner: nobody
Type: Uncategorized | Status: new
Component: contrib.auth | Version: 2.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
Duplicate of #20218? Probably a discussion on the DevelopersMailingList is
needed to find a consensus about what change to make.
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:7>
Django
Reporter: Mehmet Dogan | Owner: nobody
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
Reporter: Mehmet Dogan | Owner: nobody
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
Description changed by Mehmet Dogan:
Old description:
New 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29012#comment:9>