verifyPassword endpoint should accept POST

[cbaker6]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

verifyPassword currently only accepts get. Most of the endpoints have been moved to accept POST, but not this one. When using GET with verifyPassword, it sends the username and password being verified allowing this data to be cached.

parse-server/src/Routers/UsersRouter.js

Lines 493 to 495 in 350b59a

	this.route('GET', '/verifyPassword', req => {
	return this.handleVerifyPassword(req);
	});

Feature / Enhancement Description

Use POST instead and SDK's should change to POST. I currently only found this being used in the JS SDK, though I have an implementation of it for the Swift SDK that I haven't merged yet. I don't plan on merging the Swift version with GET. Of course, it can also be accessed via REST.

Maybe get rid of GET here? Maybe it's needed for backwards compatibility? Just a thought...

Example Use Case

1. User is logged in
2. User attempts to verify their password. Hit the verifyPassword endpoint with a POST (instead of GET)

Alternatives / Workarounds

Use GET or don't use verifyPassword/

3rd Party References

Previous Issue #4052, PR: #4268

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

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

[mtrezza]

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.