In my previous post, I wrote about setting the stage to write test cases.

My next step would be to configure the authentication module as that is one of the most important as well as mandatory features of any app. How should a User sign up, What would be the mode of authentication, and What privileges do they have - these are the first set of questions that need to be answered.

As far as django is concerned, there are a good number of options when it comes to User authentication & authorization. With pydanny's cookiecutter, almost all properties be out of the box if you plan to use the default authentication mechanism.

django.contrib.auth and django.contrib.contenttypes will be present by default under DJANGO_APPS in your base.py. Likewise, SessionMiddleware and AuthenticationMiddleware will also be automatically added under MIDDLEWARE section.

One will execute the migrate command at this stage if one plans to make use of the default authentication system.

python manage.py migrate

This creates the necessary database tables for auth-related models.

So why would anyone want to replace the default user model? Here are a few reasons that I've come across:

Per django's documentation on User model, it comes with the following fields primarily:

• • username

    • password

    • email

    • first_name

    • last_name

Other than these, there are other group-related fields like is_staff and is_superuser and fields.

• One primary reason why one may want to override is when we need additional fields on top of the above-mentioned fields. What if I need to maintain the profile picture of a user, and their phone number which is quite a common scenario

• When we would want to use email for authentication rather than the username. These days, it's quite uncommon to see login by username. Most of the time we just have a display name to use in the app's forums.

• If we wouldn't want our usernames and emails to be case insensitive then we may have to override as the default is case sensitive when it comes to username and email

• One more common requirement may be to use social login (google, facebook, twitter, github, etc.,) or multi-factor authentication. In this case, we may have to use additional packages, and perform additional steps to integrate

Reason for overriding in Wobu

I decided to use email to log in to the Wobu app. That was the primary reason to extend. I will be adding more fields like an avatar of the user, and a display name as of today. I may add a few more in the future.

Common methods to customize the default

Extend AbstractUser

This can be used when we need to add additional fields on top of already provided fields. Other default functionality will be intact

Extend AbstractBaseUser

This can be used when we need to completely strip down to two basic fields, password and last_login and build whatever we require completely on our own. There is also a provision to change the default USERNAME_FIELD to any unique field, it need not be username after all

In Wobu's case, I took the second route as the same primary reason for signing in using email holds good. I also anticipate adding quite some fields to the user model.

It may not be the best approach to add fields at a later stage. So, I shall freeze the fields in User Model very soon.

That's all for now. I'll come back with another post very soon 👋