[Django] #29012: Coordination of Authorization Backends in Permission Checking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
#29012: Coordination of Authorization Backends in Permission Checking
-----------------------------------------+------------------------
               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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/051.cb2b7378004c7015bd380b9163b2fb91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.6189bb7f58a14e010aa31a5eec886dfe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.b289a9ad797824de133391242834aa35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.2469474b57d50f47a5ef0ad0b6171c65%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.d15d2f1f1b5be881715c3cef18fd706f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.7880316a140b6e2447ee10e1585fd6e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.b65ea894a1cbee8350c2f33e56b206a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#29012: Coordination of Authorization Backends in Permission Checking
-------------------------------+--------------------------------------
     Reporter:  Mehmet Dogan   |                    Owner:  nobody
         Type:  Uncategorized  |                   Status:  new
    Component:  contrib.auth   |                  Version:  2.0
     Severity:  Normal         |               Resolution:
     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 <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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.dbb801b3e0f3ab4911b3f14d463ea982%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Django] #29012: Coordination of Authorization Backends in Permission Checking

Django
In reply to this post by Django
#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
-------------------------------+--------------------------------------
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>
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/066.71ea0989ffd4ad7548d60d0cc67eeda1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.