Code

Opened 8 years ago

Closed 7 years ago

#2630 closed enhancement (invalid)

[patch] custom authentication with models.Model in django.contrib.auth.backends

Reported by: erob@… Owned by: erob@…
Component: Contrib apps Version: master
Severity: normal Keywords: ModelBackend
Cc: erob@… Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

hi - here's a work-in-progress patch which should allow people to specify alternate
modules for authentication. In short, it introduces another variable in the user
settings file, which serves as the starting point for custom authentication.
If the user still cant authenticate agaisnt that model, then it fallback on the
User object. Please tell me if that works for you, since it's still work-in-progress
and it needs to be polished a lot.. :-)

Attachments (1)

backends_custom_auth.diff (2.1 KB) - added by erob@… 8 years ago.
here's initial revision -- comments are encouraged!

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by erob@…

here's initial revision -- comments are encouraged!

comment:1 Changed 8 years ago by ubernostrum

How does this differ from what you can already do with custom auth backends?

comment:2 Changed 8 years ago by ubernostrum

Also, using objects really isn't safe, because there's no guarantee that a given custom model will have a manager by that name -- using _default_manager, however, will always work.

comment:3 Changed 8 years ago by anonymous

ubernostrum: the reason i wrote this is for experimenting authentication with custom models.
If it works, i think it would be simpler (from a user-perspective) to just use django.contrib.auth.backends.ModelBackend instead
of writing a custom backend. But yes, the latter option seems equivalent, if such a backend
would allow user authentication with anything else than the User class. I dont know how to use _default_manager - can you
pls give an example? :)

comment:4 Changed 8 years ago by ubernostrum

Well, ordinarily if you grab a model, you think to do:

model.objects.filter(some_arg=some_val)

But because people can set up custom managers and avoid having the default objects manager, there's no guarantee that will work -- it's quite possible that you'll just get an AttributeError because someone's model is using a manager that's not named objects. To work around this, the attribute _default_manager always gets you the model's default manager, no matter what that manager happens to be called. Which means that doing

model._default_manager.filter(some_arg=some_val)

should always work, even when there's not a manager named objects.

comment:5 Changed 7 years ago by anonymous

Milestone Version 1.1 deleted

comment:6 Changed 7 years ago by Simon G. <dev@…>

  • Resolution set to invalid
  • Status changed from new to closed

Marking invalid following Ubernostrum's comments above - please re-open if you disagree.

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.