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.
💡
Make sure you execute this command only after you decide which User Model you plan to use. It becomes difficult to do it at a later stage.
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 👋
