Problem:
Currently, when we initiate a password reset through the sendResetAccountPasswordEmail, the authorization plugin prepares an email with the following reset URL:
|
const url = `${STORE_URL}/?resetToken=${token}`; |
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.
Problem:
Currently, when we initiate a password reset through the
sendResetAccountPasswordEmail, the authorization plugin prepares an email with the following reset URL:reaction/packages/api-plugin-authentication/src/util/accountServer.js
Line 41 in ecb8ef6
Where
STORE_URLis a configurable environmental variable andtokenis the password reset token provided byAccounts JSthat should be used later in theresetPasswordmutation.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:
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_FRAGMENTand turn the password reset URL into:If we provide the default value of this env var to be
?resetToken=, it will support backward compatibility.Technically we can set the
STORE_URLto a more specific route likehttp://localhost:4000/password-resetthat 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.