Building User Flow

Getting Set Up

First of all, we will create a directory and inside that directory make one project by running the following commands. Here we are creating a project with the name my site.

Now after creating the project change the directory to go inside the project directory and run the following command:

Now create one app by running the commands given below. Here we are creating an app with the name myapp.

Standard User Model

Access control and personalized application state are the two main reasons why a user account concept exists. Through access control, resources available in the system are only available to particular users only. The personalized state may involve data, settings, or any other records specific to a particular user. But it has heavy dependence on the application purpose. The approach for both cases is provided by the User model of Django. Django applications have two types of users: Regular users and superusers. Every attribute and privilege of a regular account is provided to the superuser. It also has permission to access the Django admin portal. Any data Deletion, creation or updation, etc. actions can be performed in the application by the superusers, it may be performed by other user accounts. Run the below command for the creation of a superuser in your Django application.

User accounts allow storing their data in the database. By default in Django, there is a need for two basic fields only i.e, a username and password. But some additional fields are also provided by Django so that users can enter their first name, last name, and email address also.

Security and Reliability

Substantial password Management middleware is involved by Django along with the user model. User passwords must consist of at least 8 characters, all characters must not be a number, the password must not be similar to the username, and most importantly it is not to be one from the list of 20,000 common passwords.

It is the responsibility of the Django stock form to check all these requirements. With the help of the PBKDF2 algorithm along with a SHA256 hash, the password is converted into an encrypted form when it is sent to the intended server.

So robust security is provided by the default password system of Django without any developer effort. And another important convenience provided by Django is the requirement for the uniqueness of the username. This is because if two users are having the same username i.e. “djangouser1” and the login request is received by the server from this server then how it will get to know which access request is from which user? So when the second tries to register with an already existing username then they have to pick a different name. Django provided forms to verify the uniqueness constraint but it is enforced at the level of the database.

Now let us talk about user deletion. There may be a possibility in the user deletion that every user account is tied with many resources in the complex applications. Set the is_active field of the user to false if you want the effective user deletion without attached object removal.

Then after the account deletion, resources remain attached to that account. And superusers can re-activate the account at any time.

Note that the username is not freed up by it, but we can achieve it by deactivating the account of the user and modifying the username to any random unique name. The is_active option is not suitable when you want to fully delete your user account. For registration of a new user account, we need to write below in the views.py file

Code Explanation:

• Already signed-in user is redirected away from the signup page
• And then checking the request method if it is POST, then this indicates that the user creation form is filled already and now it is required to create the user.
  • Firstly, the form object with the data provided by the user is created on the backend.
  • User is created if the form is valid and logs the user in and then redirects the user to the main page.
  • Otherwise, the user is redirected back to the user creation page along with the information of invalid data(such as the username sent in the request is already existing)
• Otherwise the user is required to meet with the form for new account creation.

Code for sing-in

Code Explanation:

• Already signed-in user is redirected away from the sign-in page
• And then checking the request method if it is POST, then this indicates that the user creation form is filled already and now it is required to authenticate the user.
  • Firstly the user is authenticated with the data provided by it.
  • Login to the user if the username and password entered by the user is corresponding to the account.
  • Else send the user back to the sign-in page along with the information already filled in the form.
• Otherwise the user is required to meet with the form for new account creation.

Code for signout request:

After login the user the session is established and it will last until the user will not log out. And at this time, account-only page access is provided to their browsers' subsequent request. Multiple sessions for one user can be active at a time. There is no time_out in the sessions by default. Standard views, forms, and routes are provided by the stock authentication views for user management, and custom template passing, custom URLs assignment, or views subclassing can be used to achieve more control and modification.

Extending the User Model

The user model is required to expand for storing more data of the user per account or for providing finer-grained access controls.

Dropping Fields from the User Model

For the user by default, only the username and password fields are needed. Creation of a user is also possible without providing the email_address, first_name, or last_name so simply ignore the existence of additional fields if there is no need of using any other field. There is also a default field collection that contains some default fields such as data_joined and last_login and it can also be ignored if not desired. The general reason for the field dropping from the user model is to drop the username field for using email for unique identification. It can be simply done by the following process: During the user creation by form data or request authentication, enter the email address simply just like entering the username. Uniqueness constraint is still enforced after formatting the usernames as email addresses. Because an email address is also treated like a string.

Adding Fields with a User Profile

The default user model can be modified if extra information about the users is needed to store. It can be even done for a single field, by defining an object, and a one-to-one relationship is established for this with the existing users. The profile can often be a name for this extra model. Let us assume for every user we want to store the date of birth(dob) and middle name. The model Profile is defined by the code given below and it is written in the models.py file.