#27528: No default object-level permissions provider
-----------------------------------------+------------------------
               Reporter:  Jamie Bliss    |          Owner:  nobody
                   Type:  Uncategorized  |         Status:  new
              Component:  contrib.auth   |        Version:  1.10
               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              |
-----------------------------------------+------------------------
 By "object-level permission", I mean if an object was passed to
 has_perm().

 The expected default behavior would be that the object is ignored and
 general permissions are used.

 However, the current default behavior and configuration is that all
 object-level permissions are false. That is, has_perm('myapp.myperm') may
 be True, but has_perm('myapp.myperm', mymodel) is always False.

 There is no built-in method to enable object-level permissions to function
 at all in any form. I have attached the snippet I use for this.

 The biggest problem is that this misbehavior does not appear to be
 documented anywhere and there are no warnings. Diagnosing this
 misconfiguration required splunking through source code.

 In addition, this bug ripples into the ecosystem. No third-party
 applications can expect object-level permissions to function without
 additional third-party software and configuration, even in situations
 where the user does not want ACLs or other advanced permissions systems.
 That is, currently applications must choose between: 1. Using object-level
 permissions and requiring users to install additional software; 2. Using
 only general permissions and not supporting ACLs, etc without a patch; 3.
 Have an application-specific configuration option and some
 wrappers/boilerplate to toggle between using object-level and general
 permissions (which every application making this decision would need a
 copy of).

 If nothing is actually fixed, please, at the very least, document this
 weridness.

--
Ticket URL: <https://code.djangoproject.com/ticket/27528>
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/057.34df4ddcfa35a2758cf9c1c8b76b2133%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to