verifyPassword endpoint should accept POST #7784

Activity

1. parse-github-assistant commented on Jan 24, 2022

   

   parse-github-assistantbot

   on Jan 24, 2022

   Last edited by parse-github-assistant

   More actions

   Thanks for opening this issue!

   • 🎉 We are excited about your ideas for improvement!
2. mtrezza commented on Jan 24, 2022

   

   mtrezza

   on Jan 24, 2022

   Last edited by mtrezza

   Member

   More actions

   I also think it should be POST because:

   • the request changes something on the backend, so according to http spec it should not be GET
   • username potentially an email address) is PII and should not be in logs

   👍React with 👍1Reacted by Corey
3. mtrezza

   added

   type:featureNew feature or improvement of existing featureNew feature or improvement of existing feature

   on Jan 24, 2022
4. mtrezza commented on Jan 24, 2022

   

   mtrezza

   on Jan 24, 2022

   Last edited by mtrezza

   Member

   More actions

   Mixed up the endpoints in my previous comment, verifyPassword is not changing anything on the backend side, it's an idempotent operation, which speaks for GET. However, the HTTP specs allow to use POST for idempotent ops if there is a good reason, which I think is given considering that we don't want sensitive info in logs.

   This almost contradictory spec of RFC2616 / HTTP/1.1 which implies that an idempotent request has to expose parameters as part of the URL due to lack of a request body is slowly softening up. RFC 7230-7237 (2014) does not explicitly demand that the request body of a GET request should be ignored. This opens up the possibility to add a body to a GET request. However, we may run into compatibility issues on systems where the request is parsed in a "conservative" way and any body of a GET request being discarded.

   So for the time being, switching to POST seems to be the way to go.

   👍React with 👍1Reacted by Corey
5. dblythy commented on Jul 5, 2026

   

   dblythy

   on Jul 5, 2026

   Last edited by dblythy

   Member

   More actions

   Just noting that this is already implemented - POST on verifyPassword landed via #8895. The route is registered at UsersRouter.js:860 (right alongside the existing GET), reusing the same handleVerifyPassword handler, and _authenticateUserFromRequest already reads req.body first with a req.query fallback.

   The POST + JSON body path is covered by tests too, e.g. spec/VerifyUserPassword.spec.js:609 and :649, plus the GET/POST cases in spec/vulnerabilities.spec.js. So REST clients and SDKs can use POST today and keep credentials out of the query string.

   The only leftover bits from the original ask - dropping GET entirely and switching the SDKs to POST - are either a breaking change we'd want to keep for backwards compat, or live in the SDK repos rather than here.
6. mtrezza

   closed this as completedon Jul 5, 2026