In this article, we will go over the Django User Model. We can extend it with AbstractUser and AbstractBaseUser, but what options do we have? How can we customize it and how can we use it?
The Django User Model is part of the Django Authentication package. It provides you with a standard model that is used as a backbone for your user accounts. You can find the standard fields here.
Extending the Django User Model #
There are various ways to extend the
User model with new fields. You might want to do this, when you want to add options to your users, or when you want to split them in groups (for when you have two different types of accounts for example).
Extend the Django user model with AbstractUser (preferred) #
With AbstractUser, you can overwrite the standard User model. It will inherit all functions and current fields from the standard User class and you can add anything you would like to this. Here is an example that would be in
Once you did that, you will also need to let Django know that we want to use that table as the default user table. You can do that with adding the next line to your
settings.py file (replace
<yourappname> with whatever your app name is.
Why this is the preferred method: you keep your database extremely clean as you are not creating any extra unnecessary tables (always keep database normalisation in mind!). Remember that great programmers care much more about the design and architect (that’s including the layout of your database), then the actual code. It’s way easier to refactor code, then it is to migrate your database. It’s very easy to create extra model functions for this as you have your user table in your models.
Alternatively, you could also use the
AbstractBaseUser. The difference with the
AbstractUser here is that
AbstractBaseUser doesn’t have the standard fields and functions. In other words, you will have to add all the basic items yourself. For most people the
AbstractUser will be the right fit.
Extend the Django user model with an extra model #
This works too, though you will not follow the normalisation rules that go for database tables. You will have to create an extra (unnecessary) table with this option. Extending the User model with an extra table is easy to implement though. Simply create the new table and then create a one-to-one field to the User model.
Using this approach means that you will have to call fields through the
User class. Here is an example for in your template:
As you can see, we first get the request, then the user, then the profile model that is attached to it and then the field we need. With the first method we can skip the
profile altogether as the fields are in the user model (note that profile is lowercase in this case!).
One thing you might want to consider with this method, is to immediately create your
Profile when you create the user. For this, we will have to trigger a function when a User is created. We can do that with Signals. Let’s create one for the standard User class:
Remove username from Django authentication #
There are many cases were it’s actually preferred to have users login with their email address instead of a username. A username is generally unnecessary for private applications. To remove the username, we will have to create a new User model and then assign a different
UserManager to it. The
UserManager is used to create new users. In this we will have to replace it with a custom one since we will not be creating new users like it is normally done. Here is an example:
As you can see, we are using the very bare-bone
AbstractBaseUser as we don’t need the username field and can’t change it with the
AbstractUser class. If we would have used the
AbstractUser class then we would still have to enter a username everywhere.