Code

Opened 4 years ago

Closed 2 years ago

#13933 closed New feature (fixed)

add ModelBackend inheritence to custom auth backend doc to enable Permissions

Reported by: mbg Owned by: nobody
Component: Documentation Version: 1.2
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

On http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend please consider adding some text describing how and when one might want to inherit ModelBackend in a custom authorization backend. Without ModelBackend the User Permissions are not set as expected from configuration seen in .../admin/auth/user/, e.g. get_all_permissions() returns [] unless ModelBackend is inherited or the code rolls its own Permissions.

Perhaps adding text along with an example something like the following would help:

class MyBackend(django.contrib.auth.backends.ModelBackend):
...

Attachments (0)

Change History (9)

comment:1 Changed 4 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to fixed
  • Status changed from new to closed

comment:2 Changed 4 years ago by kmtracey

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reverting anonymous close as fixed since I don't see any evidence this has been addressed.

comment:3 in reply to: ↑ description Changed 4 years ago by ramiro

  • Triage Stage changed from Unreviewed to Design decision needed

Replying to mbg:

On http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend please consider adding some text describing how and when one might want to inherit ModelBackend in a custom authorization backend. Without ModelBackend the User Permissions are not set as expected from configuration seen in .../admin/auth/user/, e.g. get_all_permissions() returns [] unless ModelBackend is inherited or the code rolls its own Permissions.

I think that is precisely what the 'Handling authorization in custom backend' section in that document says: The custom backend needs to implement its own custom authorization policies by implementing the get_group_permissions(), get_all_permissions(), has_perm() and has_module_perms() methods.

(Granted, unfortunately there is a nomenclature gray area here because what Django calls authentication backends [both built-in and external] handle in reality both authentication and authorization.)

IIRC one of the design guidelines followed when creating this pluggable backends machinery was to allow the use of classical Python techniques like duck typing instead of inheritance and this is the idea is conveyed by the text of the document. Adding an example using inheritance wouldn't be consistent with this philosophy.

Leaving ticket open open but moving to DDN.

comment:4 Changed 4 years ago by gabrielhurley

  • Triage Stage changed from Design decision needed to Accepted

Amusingly, I agree with both Ramiro and with the reporter (mbg). The current docs cover the intended usage and duck-typing strategy very well, as they should.

However, I don't think it serves the greater good to simply omit ModelBackend from that section of the docs. Adding a few sentences describing how Django uses ModelBackend should be enough to point people in the right direction should they want to go that route without explicitly recommending it.

comment:5 Changed 3 years ago by ramiro

#13466 was closed as a duplicate of this one. It asked for clarification in the docs about the fact writing and using a custom auth backend will mean it needs to perform permission checking itself.

comment:6 Changed 3 years ago by graham_king

  • Severity set to Normal
  • Type set to New feature

comment:7 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:8 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:9 Changed 2 years ago by ptone

  • Resolution set to fixed
  • Status changed from reopened to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.