override User model in Django or not?

Question

i'm currently working with Django and i have to give users the availibility to register and log. i've read many documentations, and each one recommands extending User model. Are there limits to extend User model ? Do I have to build my own app or extend User model ?

Answer 1

django 1.5 will bring custom User model :) https://docs.djangoproject.com/en/dev/releases/1.5-alpha-1/#configurable-user-model

Answer 2

At this point of time I recommend using Django 1.5 features through the dev version. 1.5 should be released end of November (if I'm not mistaken).

With it you have a new specific way of modifying the default user model and all the stuff around, so you're keeping a lot of the default goodness while customizing the model (if it's what you need to do):

https://docs.djangoproject.com/en/dev/topics/auth/#customizing-the-user-model

Answer 3

The good thing with django-registration is that it makes a distinction between gathering a enough information to register a User (which will allow them to log-in to your system), and gathering additional information about that user that would make up their Profile, such as gender, dob, etc. This second bit can be done in lots of different ways, James Bennet who is the author of django-registration also authored django-profiles which is a seperate app and allows you to flexibly build the required fields that make up a user profile.

If you want to roll your own profile solution then I wouldn't recommend actually extending (in the object inheritance sense) the Django User model, but simple specifying a foreign key relationship in an additional Model that will hold all your profile fields, you can then follow the reverse relationship to this profile model from any User instance.

For example:

class Profile(models.Model):
    user = models.ForeignKey(User)
    nickname = models.CharField(max_length=255)

>>> user = User.objects.create_user(username='a_user', email='me@home.com', password='password')
>>> profile = Profile.objects.create(user=user, nickname='example')
>>> user.profile_set.all()[0].nickname #follow the reverse relationship from the fk in Profile
example

Answer 4

This answer turned into quite a narrative, so here's the short part:

This worked pretty well for me, but you need to do extra work if you want your User subclass instead of an auth.User on your RequestContext instances.

TLDR:

I have done this in the past with the goal of switching from usernames to email-based login. This added a bit more overhead, as it required a new auth backend as well. On the plus side, replacing the auth backend results in RequestContext.user and HTTPRequest.user being instances of the custom User subclass.

In my experience, the sticky parts of extending User come when using contrib.admin.

The trick is that contrib.admin uses its own login view when an unauthenticated / unauthorized user tried to access one of the admin urls. This was immediately obvious to me when I landed on a different login page, but might not be so apparent if you haven't overridden those anyway. This also uses the standard auth backend though, so my RequestContexts ended up with auth.User instances instead of my subclass.

The solution to that was to override AdminSite and define a new login method. I just redirected to my front-end login page with a ?next.

Rather than jumping through all these hoops, a simpler solution is just to leave the auth.User in the contexts, and define a classmethod on your user subclass:

@classmethod
def for_auth_user(cls, auth_user):
    return cls.objects.get(user_ptr_id=auth_user.id)

That's just an extra db hit each page load. You could even then write a middleware to make this swap at the beginning of each request.

Answer 5

If you need more information stored in your User model check out this answer.

For user registration, there's an app called django-registration.