parse-community / parse-community/parse-server

Add password reset initiated via web form

Open
#7,210 24 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type:feature
Dominant language
JavaScript
Stars
21.4k
Forks
4.8k
Avg merge
7h 45m
Merged PRs (30d)
11

Description

New Feature / Enhancement Checklist
Current Limitation

When a user needs to change his/her password, a POST request has to be performed to the REST endpoint /parse/requestPasswordReset with appropriately filled HTTP headers, namely X-Parse-Application-Id and X-Parse-REST-API-Key.

This is typically handled via JS, iOS, or Android client side SDK, and can not be triggered via plain HTML email or HTML webpage by simply using a form, without resorting to JavaScript XHR.

Example Use Case
  1. User receives an HTML email with simple button saying: To change your password, click the button below.
  2. The button click invokes simple HTTP form POST request with username filed to a parse-server.
  3. User is redirected to a webpage saying: Instructions to reset your password were sent to your email address.
Feature / Enhancement Description

I would like to offer my users a feature where they can change their password by clicking a link directly from HTML email, by simply HTTP POST-ing their username (email address) to some API endpoint to avoid use of client side JavaScript.

After they click the link, they should be redirected to a page informing them that the instructions to reset the password were sent to their email address.

Looking at the current state of https://github.com/parse-community/parse-server/blob/master/src/Routers/PublicAPIRouter.js I propose to modify POST to /request_password_reset to start the password reset flow when only username is present.

This is in line with how the /resend_verification_email endpoint works.

The functionality will then be as follows:

  1. HTML email uses a form and button that does POST /request_password_reset that requires username. Parse Server generates password reset token in a db, sends password reset email with username, and token, and redirects to password_reset_initiated.html.
  2. password reset email contains button with link to: GET /request_password_reset with requires username, and token, and redirects to choose_new_password.html
  3. choose_new_password.html form prompts for new password, and submits to:
  4. POST /request_password_reset with username, token, and new_password.
  5. Password is changed in a db, when token valid, and user is redirected to password_changed.html, or to invalid_link.html when token already expired.

Example implementation is provided here: https://github.com/parse-community/parse-server/pull/7207

Alternatives / Workarounds

The only alternative I am aware of is to use client side JavaScript and XHR to trigger the password reset flow by posting to /parse/requestPasswordReset endpoint, handling the response, and changing the HTML DOM appropriately to indicate that instructions were sent to email address.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading src/Routers/PublicAPIRouter.js and reviewing the example implementation in pull request 7207. Trace the existing password-reset and resend-verification flows, then compare them with the requested form POST, token validation, redirects, and password-change steps. Done means the complete flow works without client-side JavaScript and handles expired links.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, nodejs
Domain
api, authentication, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.