[RUBY] Rails tutorial (6th edition) Background operation of password reset function

table of contents

1. Create new account
2. Login (including Friendly Forwarding and persistent login) (https://qiita.com/akarin0519/items/f241b9699e156741a8d1)
3. Edit Profile
4. ** Reset password **
5. Posting a Micro Post
6. Follow and unfollow

4. Reset password

Operation screen

Resetting the password proceeds in the following 4 steps.

1. Click the password reset link to display the email address input form.
2. Enter your e-mail address and press the send button, and a password reset e-mail will be sent to the entered address.
3. Click the link in the password reset email to display the password entry screen.
4. Enter the password and press the send button to reset the password and log in to the home screen.

Background operation

The background operation in each of the above steps will be described below.

1. Click the password reset link to send a GET request to the/password_resets/new path and perform the new action on the Password Resets controller. This new action only displays the corresponding view (/password_resets/new.html.erb). In addition, this view is an input form of the destination to send the password reset mail, and the destination address is stored in params [: password_reset] [: email].
2. Enter your email address and press the submit button to send a GET request to the/password_resets path and execute the create action of the PasswordResets controller. In this create action, first, the email address stored in params [: password_reset] [: email] is received, and the corresponding user is searched from the DB using the received address as a clue. Then, when the corresponding user exists, reset_token is issued, and the token issuance date and time and the value (reset_digest) obtained by digesting reset_token are saved in the DB. Next, send a password reset email and embed the link to/password_resets /: id/edit here. However, the: id part of this URL is actually reset_token, not the user ID, and includes the email address as a query parameter.
3. When the user clicks the/password_resets /: id/edit link in the password reset email, the Edit action of the Password Resets controller is executed. To be precise, just before the edit action is executed, the corresponding user is searched from the DB using the email address (params [: email]) received as a query parameter as a clue, and (1) whether or not the corresponding user exists. (2) Whether the user is enabled (3) Whether the user's authentication succeeds (in this case, whether the digested value of reset_token matches the reset_digest saved in the DB) (4) Checking if reset_token has expired. And, in this edit action, only the corresponding view (/password_resets/edit.html.erb) is displayed, and this view is the input form of the reset password. In this input form, the address (params [: email]) received as a query parameter is passed to the hidden field. The password entered here is stored in params [: user] [: password].
4. When the user presses the submit button on the input form, a PATCH request is sent to/password_resets /: id and the passwordResets controller update action is executed. Immediately before executing this update action, as in the case of the edit action, the corresponding user is searched from the DB using the email address (params [: email]) prepared as a hidden field as a clue, and (1) the corresponding user exists. (2) Whether the user is enabled (3) Whether the user's authentication is successful (4) Check whether reset_token has expired. In this update action, the password is received from params [: user] [: password], the DB is updated, and if the update is successful, the reset_digest value is deleted and redirected to the home screen.