You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Normally, it is not possible to use /v1/users/reset/initiate to learn whether a particular email exists on a Central server: if the specified email exists, the endpoint returns a successful response, and if it doesn't exist, the endpoint returns the same successful response. That is also true if the query parameter ?invalidate=true is specified, as long as valid auth is provided. However, if valid auth is not provided, ?invalidate=true can be used to check the existence of a particular email: if the specified email exists, the endpoint will return a 403, but if it doesn't exist, the endpoint will return a 200. That's because the endpoint only checks auth if it will take an action that requires auth, which only happens if the email exists. Instead, I think that if ?invalidate=true is specified, the endpoint should always check auth. That would mean that even if the specified email doesn't exist, the endpoint will return a 403 if valid auth is not provided. With that change, it would no longer be possible to use the endpoint to check the existence of a particular email.
The text was updated successfully, but these errors were encountered:
@sadiqkhoja, I noticed this issue while reviewing #472. In case it's of interest, I thought I'd mention it to you, since you're already familiar with that endpoint.
sadiqkhoja
added a commit
to sadiqkhoja/central-backend
that referenced
this issue
Apr 20, 2022
* bug #473: check auth if invalidate is true, should return 403 even if account doesn't exist
* incorporated PR feedback, check auth before checking email ever existed
* fixed indentation
* renamed test case and fixed style
Normally, it is not possible to use /v1/users/reset/initiate to learn whether a particular email exists on a Central server: if the specified email exists, the endpoint returns a successful response, and if it doesn't exist, the endpoint returns the same successful response. That is also true if the query parameter
?invalidate=true
is specified, as long as valid auth is provided. However, if valid auth is not provided,?invalidate=true
can be used to check the existence of a particular email: if the specified email exists, the endpoint will return a 403, but if it doesn't exist, the endpoint will return a 200. That's because the endpoint only checks auth if it will take an action that requires auth, which only happens if the email exists. Instead, I think that if?invalidate=true
is specified, the endpoint should always check auth. That would mean that even if the specified email doesn't exist, the endpoint will return a 403 if valid auth is not provided. With that change, it would no longer be possible to use the endpoint to check the existence of a particular email.The text was updated successfully, but these errors were encountered: