Andrew, After further thought I came to think that, even if multiple options kept in the framework forever, the disadvantages will not be considerable. I still think it will limit inter-changeability (what is the word for this?), but most people/backends would follow the one that makes more sense, so it will should not be an issue.
Sent from Mail for Windows 10 From: Mehmet Dogan Sent: Thursday, January 18, 2018 2:04 PM To: django-developers@googlegroups.com Subject: RE: Default Authorization BackEnd Denying Permissions ifObjectProvided Andrew, > Why you would use the user API if you cared about a specific backend? True. I wouldn’t. > Using your example of the RolesBackend, either > A) You want to leave it up to the user whether a role grants object level > permissions or not. > B) You want to have consistent behavior for your backend. Seemed like I wanted consistent behavior without relying on any particular backend. But, I see this restricts the design choices elsewhere or for others. Whether advantages outweigh disadvantages, or vice versa, I am not sure. I was envisioning that one who uses multiple backends, say at least 3, would get everything needed through the common API, as well as seamless reusability of backends within each other. But your scenario B gave me some ideas for backup. Thanks 😊 Mehmet From: Andrew Standley Sent: Thursday, January 18, 2018 1:29 PM To: django-developers@googlegroups.com Subject: Re: Default Authorization BackEnd Denying Permissions if ObjectProvided Hey Mehmet, If a backend relies on PermissionAuthorizationBackend, and another require the ModelOnlyPermissionAuthorizationBackend So I think this is the point that confuses me. Why you would use the user API if you cared about a specific backend? Using your example of the RolesBackend, either A) You want to leave it up to the user whether a role grants object level permissions or not. B) You want to have consistent behavior for your backend. Explanation: A) In this case you would use your pseudo code example. To return true (proposed) for an object when a user has the model level permission (ie a role with this permission) the user would configure their setting so ``` AUTHENTICATION_BACKENDS = [ 'PermissionAuthorizationBackend', 'RolesBackend', ] ``` To return false (current) for an object when a user has the model level permission the user would configure their setting so ``` AUTHENTICATION_BACKENDS = [ 'ModelOnlyPermissionAuthorizationBackend', 'RolesBackend', ] ``` In either case the backend order does not particularly matter for this example. B) In this case the backend should derive or call the backend whose behaviour it requires. ``` class RolesBackend(PermissionAuthorizationBackend): def has_perm(self, user_obj, perm, obj=None): ... for delegate in delegates: if super(RolesBackend, self).has_perm(user_obj, perm, obj): return True return False ``` Cheers, Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5a610980.8a40ca0a.70bfa.42b3%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
