Allow for extendable auth_user module

auth_user_module patch

updated patch, fixes typo in previous file

Bugfix: This version plays nicely with syncdb and works with the django.db.models.loading.get_model(....)

Milestone Version 1.0 deleted

Cool, I didn't know this ticket existed. This was something I have been wanting to do but never found the time.

Thanks for the patch, I think you are headed in the right direction. I would say most of the existing methods that were left in UserTemplate? should move along with the User model though. Take set_password for example, this would only work for a user model with a password attribute. By default, set_password should do nothing. Other methods like get_absolute_url and is_authenticated could stay since they would be sensible defaults the way they exist now.

Marking this as accepted as this has been a highly desired feature for quite a while.

patch against [4462]

#3669 marked as a duplicate, and has some other ideas.

patch against [6023]

oh sorry, my previous patch was against newforms-admin branch, here's the patch against trunk [6023]

+1 on adding this feature.

Email, rather than username, certainly seems to be the standard these days for web authentication. Problem is, the User model only gives us a 30 character primary key field to work with.

I'm a big +1 for any improvement that would allow us to easily use our own model in place of the User model.

I'm +1 on this. It would be extremely useful to have custom user models especially when dealing with things like openid.

+1. This would be great. What does it need to be included? Tests? Docs? How can we help?

Looks to be in scope for 1.0.

Funny I found this ticket (again). This is something I wanted to add to django for ages now, but going an rather radical approach. Instead of just being able to plug another User-model in I decided it would be nice to create a modular auth-framework, which lets you replace the permission-system as well, as I think "auth" are two parts: AUTHentication (who is requesting a page) and AUTHorization (may he request that page).

I filed a bug about this, too (#3669)...but it got closed (duplicate of this here). So - because it looks like things are getting forward here - I just wanted to get some discussion up again about this.

What do you think about going one step further and also create a modular permission system? What I implemeneted so far is a simple hook-system, using some ideas of the generic-auth-branch.

Would it be possible to make it a user-choice to include (or exclude) thinks like the existing permission, group and message-models in auth or even replace this parts, too?

Perhaps there can be shared some code or ideas? Some outdated code is available at https://svn.webmasterpro.de/django-auth-rewrite/

Anyway, I'm +1 for getting this integrated of course. ;-)

+1

I'd like abstract models for permissions, groups and the admin stuff (is_superuser, is_staff, ..). Don't require any particular fields (auth backends may provide suitable mixins).

Something like the following would then be equivalent to the current User implementation:

from django.contrib.admin import AdminUserMixin
from django.contrib.authorization import UserWithGroupMixin, UserWithPermissionsMixin
from django.contrib.auth.backends.model import ModelBackendUserMixin

class User(UserWithPermissionsMixin, UserWithGroupMixin, AdminUserMixin, ModelBackendUserMixin):
    first_name = models.CharField(_('first name'), max_length=30, blank=True)
    last_name = models.CharField(_('last name'), max_length=30, blank=True)
    email = models.EmailField(_('e-mail address'), blank=True)
    last_login = models.DateTimeField(_('last login'), default=datetime.datetime.now)
    date_joined = models.DateTimeField(_('date joined'), default=datetime.datetime.now)
    ...

(Not thought through: ModelBackendUserMixin could be a factory: class User(ModelBackendUserMixin(identity='email', password='password')), or would a metaclass solution be nicer ..)

Brought proposed patch up to trunk and moved some methods around; added stub documentation.

Last patch didn't include django/contrib/auth/default_user.py, which is where the, er, well, default user lives. Kind of important.

An enhancement, not 1.0.

Patch against [7832] and added a quick fix so that apps like contenttypes wouldn't think that the imported module was part of contrib.auth.

So there are several major issues here, probably the largest being how we can make this integrate with the admin interface (perhaps we should be doing this on newforms-admin?) and current generic apps.

I would like to find a way to make it dynamic rather than just saying, "Oh, you're using your own user model, sorry you're SOL if you want to use this and this and this."

I'm also in now way sure that the current method of doing it is the proper one, but now that the diff is current we can at least figure out where to go from here.

Anybody volunteering or have any ideas?

I like the idea of duck typing. If your provided user model has x, y, and z fields or properties, and X, Y, and Z methods, then the default admin and other apps will accept it and use it as if it were the default. That way, if you want your own model to be used by the admin, you make sure those properties and methods are available and work. We can even provide an AuthUserTemplate? that have stubs that raise a NotImplementedError?. (I don't know what you normally do for the properties though.) Similar to how the HttpResponse method has checks for _is_string, I can imagine that the user module loading mechanism checks these properties and fields and adds a _is_auth (or something) that the various other subsystems can check against.

So, this one will get a little shorter, I way right through with my comment when firefox crashed...great.

What I did, when trying to solve this (see #comment:11) was to strip down django.contrib.auth to only provide some generic API for all common auth-related stuff. So django.contrib.auth would only provide some API, which functions/methods just wraping the real functions/methods provided by the module(s) defined in django.settings. Additionally I was able to split the rest of django.contrib.auth into separate applications, so django got independent modules for users (auth_user) and permissions (auth_model_perm), but is not limited to this applications (for example groups could get its own application or the whole auth-backends-system could get its own user-application, removing the need of supporting backends in the main auth_user-application). Users could then use the django-users in combination with some self-written permission-system (supporting object-level-permissions for example), or do it the other way round (thats what the current patch provides).

However my code was never ready and did not solve every problem, first of all when dealing with backwards compability. I tried to set sane defaults (current applications as default selected modules) and provide support for old code, like imports (from django.contrib.auth.models import User), but thats only the tip of the iceberg.

But I think the direction my approach went was not all bad, it provided the developer with an API for all auth-related stuff and supported him with sane defauls (thats what the current auth-application does). Anyway someone could replace this with its own implementation while keeping third-party applications supported (google code lists many projects, many of them use django.contrib.auth some way), even for permission tasks (thats something generic-auth tried to solve).

Of course there needs to be some work done to provide some defaults (e.g. users should at least be displayable in templates using {{ user|escape }}), but not everything is really needed. For example the message-system is nice, but most applications won't use it. Perhaps a cleanup of the auth-application could make this optional and provide some simple way to test for message-support in third-party-applications (if hasattr(request.user, 'send_message')?). But that would be post-1.0. ;-)
(And btw: I really like the idea of using mixins here)

patch number 6 won't work if you don't override the user model. I guess it needs to conditionally delete the entry.

might also want to set the table name on the default user to auth_user

My current change includes making UserTemplate? abstract, and setting db_table = "auth_user" on DefaultUser?. This should ensure that this patch doesn't change default installation table names. I haven't verified that yet though.

This is great. Just what I've been looking for. Can we change the name of the settings variable, though? I think good naming is really important, and calling it AUTH_USER_MODULE when it doesn't name a module is a bad idea. Can we call it AUTH_USER_MODEL instead?

Uh oh... I just submitted a comment and left everything else set to the defaults, which appears to have inadvertently changed the ticket state. Can someone undo that?

Nearly there

After reviewing your patch, I just wonder why don't you put default fields and methods in the abstract TemplateUser? class? This way, you don't have to copy/paste most of the content of User class in your custom one and you can still override some of them with your own if you want. Make sense?

ps: maybe AbstractUser? is more descriptive than TemplateUser??

I'd like to see #3400, and #9463 in with this. For sorting and filtering user data across the user profile field.

Replying to cornbread:

I'd like to see #3400, and #9463 in with this. For sorting and filtering user data across the user profile field.

With extendable User-models, profile-models are no longer needed making #9463 redundant.

Too bad that it has been rejected for "too many potential downsides" from 1.1 roadmap http://code.djangoproject.com/wiki/Version1.1Features

What's the status of the latest patch? Is there somebody still active on this feature?

Strange development, that. I thought I was paying close attention to the 1.1 process, this feature getting +0 and then one -1 so I expected it to be deferred. I can't find any list of the many potential downsides anywhere, and the comment to the guy who set it -1 seemed like a comment to a -0-feature so I thought it was just a goof...

The "many potential downsides" ought to be listed here, anyway.

Replying to HM:

Strange development, that. I thought I was paying close attention to the 1.1 process, this feature getting +0 and then one -1 so I expected it to be deferred.

More than one -1 now (from http://spreadsheets.google.com/ccc?key=pSqnCvef6OXmGWQ9qbEVMeA):

• AH: Any sort of framework-in-the-framework like this makes me suspicious, and the implementation and design would have to be incredibly solid.
• JB: Doesn't affect me one way or another.

There's also one +1, from GW.

But from this to "too many potential downsides"? *scratches head*

Replying to HM:

But from this to "too many potential downsides"? *scratches head*

You might want to take a look at this #django-dev IRC channel log for a related discussion: http://oebfare.com/logger/django-dev/2008/11/25/1/#17:32-977590

So, what's going to happen with this ticket? It's on the list of ideas for Summer of Code 2009.

We really need this feature and we'd like to have an officially supported API for this. Django's default user comes with first_name and last_name which is too specific for us. We only have full_name and calculated @property for first_name and last_name. Also, we don't have usernames. In a lot of cases email is sufficient, so why should the user bother about inventing a username? Of course, this means that in our case email should be a required and unique field.

Moreover, code that uses get_profile() is just more annoying to write and you have to call select_related(). It's much easier to have all user fields in the User model. Our code has definitely become easier to work with since we eliminated the profile model and put everything into the User.

In our app-engine-patch project (a Django port to App Engine) we have something similar: http://code.google.com/p/app-engine-patch/wiki/CustomUserModel

We also allow for overriding the AnonymousUser? (which sometimes needs additional attributes, too).

Now that I think about it, the AUTH_ADMIN_MODULE stuff isn't necessary because you can easily register this in some other app's admin.py.

One thing I'll note for this is that with the new managed option it's very easy to make these pure python changes in your own code.

And how would I replace the User model using that managed option without modifying the auth app?

Replying to wkornewald:

We really need this feature and we'd like to have an officially supported API for this. Django's default user comes with first_name and last_name which is too specific for us. We only have full_name and calculated @property for first_name and last_name. Also, we don't have usernames. In a lot of cases email is sufficient, so why should the user bother about inventing a username? Of course, this means that in our case email should be a required and unique field. Moreover, code that uses get_profile() is just more annoying to write and you have to call select_related(). It's much easier to have all user fields in the User model. Our code has definitely become easier to work with since we eliminated the profile model and put everything into the User.

There are more fundamental flaws in the current approach. For example one might need to have AnonymousUser? saved in the database, which normalized the way permission control works (permissions for the AnonymousUser? can be saved to the database).

One bit problem I see with the current contrib.auth-module is, that it combines different things. There is no need to put code for authorization (who is accessing the page?) and authentication (is someone allowed to access something?) into the same app. I would prefer having these things in different applications so they could be replaced separately. contrib.auth could provide some kind of generic API for accessing these new applications. Having all of these different apps combined in contrib.auth makes redesigning these thing much more complicated. Perhaps a first step might be creating independent apps here.

Replying to David Danier <goliath.mailinglist@gmx.de>:

There are more fundamental flaws in the current approach. For example one might need to have AnonymousUser? saved in the database, which normalized the way permission control works (permissions for the AnonymousUser? can be saved to the database). One bit problem I see with the current contrib.auth-module is, that it combines different things. There is no need to put code for authorization (who is accessing the page?) and authentication (is someone allowed to access something?) into the same app. I would prefer having these things in different applications so they could be replaced separately. contrib.auth could provide some kind of generic API for accessing these new applications. Having all of these different apps combined in contrib.auth makes redesigning these thing much more complicated. Perhaps a first step might be creating independent apps here.

I like that. Moving out the permission system would also be very useful for an App Engine port because the current Permission model complicates queries unnecessarily. You can as well just store a string like "auth.can_delete" (or a whole list of such strings) which allows for much more efficient querying on non-relational DBs. This works very well in app-engine-patch.

Design discussion in bug tickets is a really bad place, since you won't reach the right audience. We have a mailing list (django-dev) for that, please use it. be aware, though, that now (as we're entering the push to get 1.1 out the door) is not a great time for getting a lot of attention on new designs, so be prepared to raise it again in the ealry 1.2 period.

What about the new proxy Meta attribute? Did someone try to extends a User for real with it? http://docs.djangoproject.com/en/dev/topics/db/models/#proxy-models

Replying to david:

What about the new proxy Meta attribute?

I think this may help with some of the problems described here, at least some of the problems that are avoidable in pure python. Many of these things can be worked around using the advantages a dynamic language like python provides, too. For example someone could just import User and then do somethink like:

User.my_new_method = lambda self: self.something_i_want_to_do_here

This may not be as clean as using some proxy-class, but works fine and has the advantage of not needing to import some "other" user.

As said above I see more fundamental flaws in current contrib.auth. One might be that you have no clean way to replace AnonymousUser? (and put it into the database for example). Another is the combination of four or five different applications into contrib.auth (authentication, authorization, groups, messages, permissions) which goes against everything you try to teach new django-users when creating applications and makes creation of new applications for only parts of this more complicated.

There are other tickets adressing some of these issues, see #4604 for example. You may also notice, that the current patch tries to put a combination of session and user-based messages into the template context. This really would not be necessary if you could just choose between two decoupled message-apps.

@mtredinnick: I'm not sure if restructuring the whole contrib.auth-app would be appropriate in 1.x anyway, so perhaps this is something that needs to be done for some 2.x-version. I will perhaps raise this issue on the mailinglist again, when 1.2 is released.

New patch against the trunk [10115]

The patch above implements the UserTemplate? keeping the original User but using an abstract model. This implementation it's not so flexible but it keeps the compatibility with 1.0 versions. Even if this patch it's not what we are looking for I'd like to the this ticket.

Replying to seocam:

The patch above implements the UserTemplate? keeping the original User but using an abstract model. This implementation it's not so flexible but it keeps the compatibility with 1.0 versions. Even if this patch it's not what we are looking for I'd like to the this ticket.

to get this ticket*

Replying to seocam:

Replying to seocam:

Even if this patch it's not what we are looking for I'd like to the this ticket.

to get this ticket*

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 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.

I'd also love to see a username option with this. ie The ability to use the email as username.

Replying to seocam:

... , but I can't see any solution which don't break the backwards compatibility and would fix everything here.

I would suggest adding some kind of contrib.newauth (like newforms) and keeping the old contrib.auth for some time (until 2.0?). One problem I see with this would be foreign keys, but perhaps we could provide some (hackish) workaround for this.

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.

Perhaps we could put up a wiki-page to work on this proposal. I would like to write down some ideas, too. ;-)

Replying to David Danier <goliath.mailinglist@gmx.de>:

I'm using the patch (might have tweaked it slightly), and without setting an override Django works as before. I'm just about to put the patch on GitHub? git://github.com/thepian/django.git I've been thinking that a general model override mechanism would be preferable, I'm not sure what the best approach would be. I'll be at Euro DjangoCon if you want to discuss this.