User Model

Have you ever wondered how to implement authentication on your website so that not every user has the same permissions and limited functionality? Well, let's start with the topic of User Model.

Django provides a robust and versatile built-in User Model, which is an integral component of Django's authentication system. This model is designed to handle user accounts, providing essential fields and behaviors for user authentication and management. It's a ready-to-use, database-driven model that simplifies the process of handling user data, making it an efficient starting point for most web applications.

The default User Model in Django comes with a variety of fields that are common to web applications. These include:

• username: a unique identifier for the user;
• password: stored in a hashed format for security;
• Email Address: optionally used for user identification and communication;
• First and Last Name: for storing the user's full name;
• is_active: a boolean indicating if the user account is active;
• is_staff: a boolean indicating if the user has access to the admin site;
• is_superuser: a boolean indicating if the user has all permissions without explicitly assigning them.

We have already encountered the User Model when we created a superuser for accessing the admin panel. We filled in the mandatory fields: username, email, and password. All other fields are not mandatory.

Extend the Default User Model

Sometimes you may need to store additional information about users that isn't covered by the default fields, like a profile picture, bio, or contact details or if you want to authenticate users based on email addresses or phone numbers instead of usernames, you’ll need to extend the User Model.

When extending the User Model, it's important to decide whether to subclass AbstractUser (which keeps all the fields of the default User Model and allows adding new ones) or AbstractBaseUser (which requires you to define all fields explicitly, offering maximum customization). The choice depends on how much deviation you need from the standard model.

Let's redesign the Author model into a User Model with an additional field, pen_name, and add authentication via email instead of the username.

We can remove all other fields like first_name and last_name, as they are inherited from the AbstractUser model.

In settings.py, you should specify your new user model:

Where app is our app name, and Author is our model that is inherited from the AbstractUser model.

Also, we need to slightly modify the code in the admin.py file and re-register the Author model, as it is not just a model but an AbstractUser. Other codes must remain the same.

In most cases, this code is simply copied and slightly modified depending on which fields you need to add. Now, each author can register themselves on our site and have the ability to add, delete, and update books, in addition to standard viewing.