User Account Manipulation - Implementation Templates

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

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

    I must say right away that registration through social services is not considered, since in this case work with accounts remains in the responsibility zone 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 by email;
    5. Forgotten password recovery.


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

    Email Confirmation Registration


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

    At the time of registration, it makes sense to request the minimum required set of user information, limited to the email address and password .

    image


    To verify the correct input, the password is specified twice.

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

    image


    And the user is informed about this.

    The user receives a letter, clicks the link with the confirmation line, the web service determines the user by the confirmation line and registers him in the system.

    To summarize the user registration algorithm:

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

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

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

    • so that there are no problems with multiple pending registrations for a single 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 necessary form:

    image

    And save the result

    image


    Change critical settings


    The very first of the important settings that sometimes have to be changed is the password .

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

    image


    Always a new password is specified twice to prevent input errors.

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

    There are many old, successful web services that store passwords themselves in a database. 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 supplement (salt).

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

    To 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 when changing it, you should specify a password.

    image


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

    image


    And the user is informed about this:

    image


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

    image


    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 confirmation letter is received by an outsider. So that he could not assign another person’s account by simply clicking on the link in the letter.

    image


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

    To summarize the user email change algorithm:

    1. get email address and password;
    2. Compare the password hash with the hash stored in the database;
    3. if the hashes match: send an email with an address change confirmation string
    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, use a special line to determine the user and make sure the password is correct (similar to item 2);
    7. if the password is correct: replace the old email address in the database with a new one, and if the password hash is calculated using the email address, then calculate and save the new password hash in the database.

    Change Forgotten Password


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

    image


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

    image


    And the user is informed about this:

    image


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

    image


    As usual, a new password is specified twice to prevent input errors.

    To summarize the user email change algorithm:

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

    Special string identifying the user


    When registering, changing the address and changing the forgotten password, a special line (token) that identifies the user is used.

    There are two ways to generate such lines:

    First (using the database):

    Generate a random sequence and save it in the database in a separate table indicating the iduser, type, and lifetime of this message. Then, having received a similar line, refer to this table and find by iduser line . Periodically clean the table of accumulated unrealized messages.

    Second (with encryption):

    Generate a pseudo-random sequence by encrypting information aboutiduser, message type and message lifetime in the message itself. And when receiving the string, decrypt and get all the information without accessing the database.

    Here is how working with a special string ( token ) in python might look like , using the library itsdangerous

    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 line, 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.


    Also popular now: