Improve reset password API

[germanbisogno]

Is your feature request related to a problem? Please describe.
I'm fan of parse server and after playing around this great tool I found a posible case of improvement on resetting password functionality. The error messages are not localized and there aren't specific error codes when making calls to the endpoint /request_password_reset, error codes are always -1. For example:

{code: -1, error: "Failed to reset password: username / email / token is invalid"}
{"code":-1,"error":"Password does not meet the Password Policy requirements."}

So, no way for the developer to handle error codes for a custom implementation of resetting password.

Describe alternatives you've considered
This implementation will require adding new error codes to the DefinitelyTyped like:

ParseError.USERNAME_NOT_FOUND = 603;
ParseError.RESET_PASSWORD_ERROR = 604;
ParseError.RESET_LINK_EXPIRED = 605;
ParseError.PASSWORD_POLICY_USERNAME = 606;
ParseError.PASSWORD_POLICY_REPEAT = 607;
ParseError.PASSWORD_POLICY_NOT_MEET = 608;

Additional context
This is my first time contributing to this great project and I'll appreciate if this proposal can be considered for future releases of parse server.

Related features:

• Another feature that I considered that could be implemented in a separated ticket can be supporting password less authentication, I think it has been discussed already here

Thanks so much!

Awesome project guys!

[mtrezza]

Thanks for your suggestion. Feel free to open a PR and we'll be happy to review it.

• I suggest you take another look at the current error list and see if you can reuse any of these existing error codes. Also, you may want to be more specific with error codes than RESET_PASSWORD_ERROR or use an existing generic error instead.
• I suggest you think the whole process through and post a step-by-step user flow here. For example, how does the user receive the reset token?
• The PR would require test cases for each of the possible error and success routes before it can be accepted.

Note: I have removed the use of an existing domain name from the example in your comment.

[germanbisogno]

many thanks for your feedback @mtrezza! I'll take a look at your suggestions.

[germanbisogno]

hi,

I just created this PR which is WIP. Please, could someone with permissions link this issue to the PR, I'll appreciate. I created unit tests that will serve as validation and for the understanding of changes made, please, run them and check comments and failures since currently there is no implementation for new error codes. I tried to look for existing codes but none fits and for the ones that don't have code yet, I think it is worth to add them to the system.

About your second suggestion @mtrezza "I suggest you think the whole process through and post a step-by-step user flow here. For example, how does the user receive the reset token?" The current flow for resetting password won't change, it is still the same, this will be an addition of an API for resetting password.

Please, feel free to contribute to this PR, I'm excited to see if someone else is interested in this feature and can add a contrubution like adjusting/adding new error codes, checking unit tests, testing, documentation, etc.

Thanks!
Ger

[mtrezza]

The current flow for resetting password won't change, it is still the same, this will be an addition of an API for resetting password.

Then how does the user receive the token?

Edit: looking at your unit tests, I am not sure I understand the intended user flow. Can you give a step-by-step example from the user's point of view how the API would be used in the process of setting the password? Something like a simple service blueprint.

[germanbisogno]

hi @mtrezza , sure, I'll create an example. Just to understand the context, when the user requests the password reset as it is currently implemented in Parse, an email will be sent with a link with the url, if the server is configured to use customPages as the example shows:

customPages: {
passwordResetSuccess: + "/passwordResetSuccess", <-- your custom page, not necessary needs to be in parse.
choosePassword: + "/choosePassword", <-- your custom page, not necessary needs to be in parse.
},

you can customize the handling of the form for reseting the password, not need to use the default implementation since when the request is done, it sents as parameters in the url username and token, these parameters can be sent later from a custom page using a xhr call to the API in order to confirm the change of password sending the corresponding username, token and new_password.

Thanks,
Ger

[mtrezza]

Let's see if I follow, the current flow is:

1. User requests password -> app calls User.requestPasswordReset()
2. User receives email with reset link
3. User opens link and gets to page customPages.choosePassword
4. User enters new password -> form posted to /request_password_reset with user, token, new password
5. Server answers with 302 and redirects to page customPages.passwordResetSuccess

This should already be possible with AJAX to skip redirection in step 5, see #5332.

What would be the difference in this PR?

[germanbisogno]

you are right @mtrezza , currently it is possible to make ajax requests to the /request_password_reset, but the different errors validations will be thrown with the same code, let's say

{code: -1, error: "Failed to reset password: username / email / token is invalid"}
{"code":-1,"error":"Password does not meet the Password Policy requirements."}

etc, so if it is wanted to handle errors from a custom page, won't be possible since the code is alwayts -1 see

parse-server/src/Routers/PublicAPIRouter.js

Line 218 in 142eaa7

throw new Parse.Error(Parse.Error.OTHER_CAUSE, `${result.err}`);

, probably it is worth to close this PR and create a new one to handle error codes in a different way.

Feel free to close it if doesn't apply.

Thanks for all your great support on this.
Ger

[mtrezza]

If I understand correctly, this issue had 2 intentions:

• By having an API, it extends this feature to be used not only from a browser, but also from a mobile device.
• Parse errors with corresponding code will be used instead of only string messages

Does that mean that:

• your intended scope of the first point is already covered by Ajax password reset #5332?
• your intended scope of the second point is to respond with dedicated (new) Parse error codes instead of currently one generic error code and the specific error code in the body?

[germanbisogno]

yes that is correct, I thought /request_password_reset endpoint was only intended to be used only from a html page and not as an API, but since you mentioned it, I see that it can receive xhr calls too, so not necessary I think to add another api for the same purpose. About the error codes yes, in order to handle errors code in a custom page (let's say I want to translate these codes to another language) it will be better to have specific error codes for each exception, so that exception can be shown in a browser, device, etc.

thanks Manuel
Ger

[mtrezza]

About the error codes yes, in order to handle errors code in a custom page (let's say I want to traslate these codes to another language) it will be better to have specific error codes for each exception, so that exception can be shown in a browser, device, etc.

I agree that having specific error codes would be nicer than the current generic error code where a text has to be parsed on the client side. It would also be more correct, because the current error code -1: An unknown error or an error unrelated to Parse occurred. does not seem to apply because the underlying error in known and it is related to Parse.

Do you want to change the PR to introduce these new error codes?

We would not need a new endpoint for this, but it would be a breaking change in Parse Server (for the better), so it would be important that:

• The docs are updated accordingly with the new error codes (try to use existing ones where possible though)
• The change log has to include a highlighted note that this is a breaking change. You can add a draft entry to the change log as part of the PR.