-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Simplify the password reset flow #1220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
That seems reasonable to me. Want to help out? |
Sure, I'll take a stab at it. |
Only downside to this would be that if the token is indeed invalid, the user wouldn't know until actually submitting the form to reset the password. Personally, I'm okay with this since the chances of the token being invalid are slim. Are we okay with this tradeoff? |
Can we keep the validation AND add a custom choose_password page? |
I'm fine with the user not seeing an invalid token until they submit. Having the custom choose_password page is important though. |
You can already specify a custom choose password page by passing it in the customPages options. |
Correct, you can already specify a custom page. This proposal is to remove that redirect (email could contain link to your custom page from the start). I have this working I just haven't had time to clean up tests. |
@andresgarza are you working on it? |
Closing this out as it seems to have stalled out. That, and the current password reset flow is functional as is, but this would be nice to have. If there is still an interest let us know so we can reopen this and look into it with the intent to push along a PR. |
If I'm not mistaken, the current flow for resetting a password is as follow:
POST /requestPasswordReset
internally generates a token and sends an email with a link to
/apps/:appId/request_password_reset
GET /apps/:appId/request_password_reset
validates token and redirects to
/apps/choose_password
POST /apps/:appId/request_password_reset
validates token and updates user password
From what I can tell, step
#2
is not really needed. Only things I think it does is validate that the token is still valid (which is still done in step#3
) and redirects tochoose_password
.In my opinion, it would be simpler/cleaner if step
#1
sent a link directly tochoose_password
and skip step#2
altogether. This will in turn get rid of an extra validation and avoid a redirect altogether.As an added bonus for those of us with custom pages, the password reset email would in turn contain a link to a "pretty" URL instead of having to go through the parse-server URL first.
The text was updated successfully, but these errors were encountered: