-
there are two situations being addressed here:
-
situation 1: user has already been invited to cobudget, but they lost the invite email, and never had the opportunity to 'set up' [please see note at bottom] their account.
when they submit the 'forgot_password' form, an identical email to the one they were supposed to receive is sent again. this email has a link to the 'confirm_account' page, and that link has an identical confirmation_token as the email previous.
the user clicks that link, and the flow is identical to that described in the note below.
-
situation 2: user has already been invited to cobudget and user has 'set up' their account, but user has forgotten their password.
when they submit the 'forgot_password' form, a reset_password_token is generated for the user (reset_password_token, being a field on the user model).
a 'reset password' email is sent to the user. the email contains a link to a 'reset_password' page. that link contains the user's reset_password_token.
when they click the link, they are redirected to the 'reset_password' page. this page contains a form with two fields, 'password' and 'confirm password'.
on form submission, a request is sent to the API with the new password and reset_password_token.
the API attempts to find a user with the specified reset_password_token, and if a user is found, their password is updated, and status 200 is returned.
when the client receives status 200, it logs the user in and redirects them to the login page, with a toast message.
-
NOTE: 'setting up an account' goes as follows:
-
user is created with an email address and a confirmation_token.
-
user gets invite email with link to 'confirm_account' page. their confirmation token is embedded in that link.
-
the confirm_account page has a form with a name and a password field. this form is submitted along with the token.
-
on form submission, the API receives the confirmation_token, finds the user with that confirmation_token, updates that user's name and password, deletes the confirmation_token, and returns 200.
-
the absence of a confirmation_token on a user model is how the server determines whether the user has 'set up' their account yet.