Photo by Kelly Sikkema on Unsplash
#5 - Time to bring up the User module
Authentication is the entry point to any app these days, isn't it?
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 ๐