Problem:

Currently, when we initiate a password reset through the sendResetAccountPasswordEmail, the authorization plugin prepares an email with the following reset URL:

Where STORE_URL is a configurable environmental variable and token is the password reset token provided by Accounts JS that should be used later in the resetPassword mutation.

When the customer navigates to the generated link in the mail, they should land on the storefront page responsible for picking the new password.

The format of the generated URL is hardcoded in the authorization plugin and enforces the storefront to implement the password reset UI in one specific route.

An example password reset URL would look like this:

http://localhost:4000/?resetToken=awjdztqpjdasiawejaspo

This forces the storefront developers to implement a password reset login in the index route of the app which may not be desirable.

Proposed solution:

Instead of hardcoding the URL, we can parametrize it by introducing a password reset path fragment environmental variable like PASSWORD_RESET_PATH_FRAGMENT and turn the password reset URL into:

${STORE_URL}/${PASSWORD_RESET_PATH_FRAGMENT}${token}

If we provide the default value of this env var to be ?resetToken=, it will support backward compatibility.

Technically we can set the STORE_URL to a more specific route like http://localhost:4000/password-reset that will evaluate to an URL, but the name of the variable doesn't imply that it will be only used in the password reset scenario. That's why I think it's a better idea to add additional configurable fragment to provide flexibility.