User account manipulation - implementation templates

The topic of this publication is unlikely to interest an experienced web application developer.

But for those who are confronted for the first time with the need to implement work with registered user accounts, we offer a detailed, illustrated summary of the main points.

Immediately, I’ll make a reservation that registration through social services is not considered, since in this case, working with accounts remains in the area of ​​responsibility of the corresponding social services .
')
All manipulations with user accounts are as follows:

1. registration with confirmation by e-mail;
2. change non-critical settings;
3. change of critical settings - with password confirmation;
4. change of email address - with confirmation email;
5. Forgotten password recovery.

Since this article is located in the TheOnlyPage web service hub , we will use screenshots of working with this servivis as illustrations.

Registration with confirmation by email

As a rule, his email address is used as a unique user identifier, and the user must confirm its use:

At the time of registration, it makes sense to request the minimum required set of information about the user, limiting himself to an e-mail address and password .



To control the correctness of the password is entered twice.

After receiving the email and password, an email is sent to the specified address with a link containing a confirmation string . The confirmation string uniquely identifies the user who is registered.



And the user is informed about this.

The user receives the letter, clicks on the link with the confirmation line, the web service on the confirmation line identifies the user and registers it in the system.

Let's summarize the user registration algorithm:

1. get email and password
2. send an email with the registration confirmation line
3. inform the user about sending the letter
4. process click on confirmation line and register user

An interesting question is: where to store information about users who have not yet confirmed their e-mail address: in a separate table or with all already registered users.

The answer is obvious: it is better to store information about unregistered users in a separate table:

• to avoid problems with multiple unfinished registrations for one email address;
• so that there is order in working with various entities.

Change non-critical settings

The user may have some other attributes besides the email address and password . Access to editing and saving most of them should not be limited.

So that the user can simply open the required form:



And save the result

Change critical settings

The very first of the important settings that you sometimes have to change is the password .

When saving a new password , like any other important attribute of the user, you should confirm the saving by entering a password.



Always enter a new password twice to prevent typing errors.

The important point is the method of storing user password information.

There are many old, successful web services that store passwords in the database themselves. This is wrong, unacceptable and all modern web applications do not store passwords, but their hashes.

A hash is a string generated from a password and a special secret additive (salt).

Even better data protection is provided if you generate a hash, not only based on the password and secret string, but also the user's email. What makes it impossible to replace email without replacing the hash.

Let's summarize the password change algorithm:

1. get old and new passwords;
2. compare the hash of the old password with the hash stored in the database;
3. if the hashes match: calculate the hash for the new password and save it in the database.

Email change

Email is a critical attribute, so if you change it, you should specify a password.



The user must confirm the ownership of the new email address. To do this, a letter is sent to the user at the specified new email address with a link containing a confirmation string . The confirmation string uniquely identifies the user who initiated the change of email address.



And the user is informed about this:



The user receives the letter, clicks on the link containing the confirmation line, the web service on the confirmation line identifies the user and redirects him to a special page confirming the ownership of the account. In the hidden form field on this page indicates a special line that uniquely identifies the user.



The user must enter a password to confirm ownership of the account. This is necessary in case of an error in the address when a stranger receives a confirmation letter. So that he could not assign someone else's account, simply by clicking on the link in the letter.



The user specifies the password, and confirms the change of address.

Let's summarize the user email change algorithm:

1. get an email address and password;
2. compare password hash and hash stored in database;
3. if the hashes have matched: send an email with the address confirmation line
4. inform the user about sending a letter;
5. process a click on the confirmation line and display the account ownership confirmation page;
6. get a special line and user password; identify the user using the special line and make sure that the password is correct (similar to paragraph 2);
7. if the password is correct: replace the old e-mail address with a new one in the database, and if the password hash is calculated using an e-mail address, then simultaneously compile and save the new password hash in the database.

Forgot password change

When initiating a change of a forgotten password, the user must specify an email address.



After receiving the email address, an email is sent to the specified address with a link containing a confirmation string . The confirmation string uniquely identifies the user who recovers the password.



And the user is informed about this:



The user receives a letter, clicks on the confirmation link. The web service on the confirmation line identifies the user and redirects him to a special page for entering a new password. In the hidden form field on this page a special line is specified that uniquely identifies the user.



As usual, the new password is specified twice to prevent typing errors.

Let's summarize the user email change algorithm:

1. get an email address;
2. send a letter with the password change confirmation line;
3. inform the user about sending a letter;
4. process click on the confirmation line and display the password change page;
5. get a special string and a new user password, define a user using a special line and generate a new password hash and save it to the database;

Special string identifying the user

When registering, changing the address and changing the forgotten password, a special string (token) identifying the user is used.

There are two ways to generate such lines:

First (using the database):

Generate a random sequence and save it in a database in a separate table indicating the user id , type, lifetime of this message. Then, having received a similar row, access this table and find the user id by row. Periodically clean the table of the accumulated unsold messages.

Second (with encryption):

Generate a pseudo-random sequence by encrypting information about the user id , message type, and message lifetime in the message itself. When retrieving a string, decrypt and retrieve all the information without accessing the database.

This is how work with a special string ( token ) in python may look, using itsdangerous library

When generating a token

 from itsdangerous import TimedJSONWebSignatureSerializer as Serializer #   ,    #    ( )   serializer = Serializer('very_secreti_key', expires_in=60*60*24 ) #       id=1234567 token = serializer.dumps( {'newemail': id} ) } 

Having received a special string, we can extract information from it.

 #   ,    serializer = Serializer('very_secreti_key') #   : # {'newemail': 1234567} try: data = serializer.loads( token ) 

Obviously, the second method, without using an additional database table, is preferred.