#3011: Allow for extendable auth_user module
------------------------------------+---------------------------------------
Reporter: nowell strite | Owner: seocam
Status: assigned | Milestone:
Component: Contrib apps | Version:
Resolution: | Keywords: auth_user
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 1
Needs_better_patch: 1 |
------------------------------------+---------------------------------------
Comment (by seocam):
>
> I like to have some fix for this in Django, too....but I see one major
downside on the approach of patching everything together to support these
things: If you look at my proposal above you may agree, that - for example
- having AUTH_BACKENDS is not neccessary to support different backends.
One could just implement some kind of LdapUser-Model (which only has
fields, that are really needed for LDAP) and use this. You can say similar
things about AUTH_PROFILE_MODULE, which would be not neccessary any more.
>
> So perhaps instead of creating an continuous growing contrib.auth-module
it would be a good idea to concentrate on replacing it by something that
reduces the overall overhead (in code and management). For me it looks
like currently many things get patched in whithout getting down to the
real problems and by providing many half-ready solutions on the road down
to a flexible authentication system.
>
> Why half-ready? AUTH_PROFILE_MODULE is a good example here. You may use
user.get_profile() to load the profile for a particular user. But there is
no way to auto-create the profile for new users (like get_or_create()). So
you have to write your own register-view to get this working, or use some
other way to work around this (I think there is some closed ticket for
this, too).
I agree that the AUTH_PROFILE_MODULE is a half-ready solution, and I know
that the patch I'm proposing it's not a final solution as well, but I
can't see any solution which don't break the backwards compatibility and
would fix everything here.
Also add a feature that we already know it's going to be deprecated it's
not a good idea either.
So the idea here is have a long term solution which provides more much
flexibility. I'll try to create a draft spec based on what I've read until
now, and as soon as a have something I'll send in the list.
--
Ticket URL: <http://code.djangoproject.com/ticket/3011#comment:58>
Django <http://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 post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
