Parse Server responds with "Account already exists" error when it should respond with "Permission Denied" error if _User CLPs are locked down.

[drew-gross]

With the CLP's fully locked down (no public read/write/field addition), attempts to signUp with an existing username throws this error (what you'd expect if the User table had public read permission):

Optional(Error Domain=Parse Code=202 "Account already exists for this username" UserInfo={code=202, temporary=0, error=Account already exists for this username, NSLocalizedDescription=Account already exists for this username})
When trying to signUp with a new username (same CLP settings -> locked), then the normal response is given:

[Error]: Permission denied for this action. (Code: 101, Version: 1.13.0)
Optional(Error Domain=Parse Code=101 "Permission denied for this action." UserInfo={code=101, temporary=0, error=Permission denied for this action., NSLocalizedDescription=Permission denied for this action.})
For security reasons, "permission denied" should be sent if the CLP doesn't allow for it, instead of telling someone (who is probably not working in your scope of the app) valuable information.

ref #1490

[drew-gross]

@skimgosu can you check what the behaviour is like if you try this on Parse.com? There is some special casing of the _User collection on Parse.com.

[DoneStuffGetting]

Slightly different on Parse.com!

Optional(Error Domain=Parse Code=202 "username  <usernameUsedForThisRepro> already taken" UserInfo={code=202, temporary=0, error=username <usernameUsedForThisRepro> already taken, NSLocalizedDescription=username  <usernameUsedForThisRepro> already taken}

Here's the Parse Server v2.2.6 response for same situation:

Optional(Error Domain=Parse Code=202 "Account already exists for this username" UserInfo={code=202, temporary=0, error=Account already exists for this username, NSLocalizedDescription=Account already exists for this username})

Both scenarios already have the PFUser object with the username, and both CLPs are fully locked.

Which brings me to another bug! Parse.com's dashboard doesn't allow fully locking out a table. It doesn't close the CLP editor window unless you have at least 1 box ticked in advanced editor. But eh, not sure if it will need fixing :p

[flovilmart]

What should we do here. username validation occur before the CLP check.

We can:

• use indexes to ensure unicity of username and email, this way CLP will kick in before we actually do the DB call, therefore, returning the CLP error first (depends on Schemas API and other databases discussion. #1547 getting settled)
• Update the CLP strategy to be checked (very) early in RestQuery.js and RestWrite.js.
• Leave it as-is as Parse.com has the same behaviour ~ the error message.
• Something else?

[drew-gross]

Adding unique indexes where necessary doesn't need to wait for #1547 as none of the APIs are set in stone until we decide they are anyway. I also think unique indexes are the right strategy.

[flovilmart]

Closing due to lack of activity, please reopen if the issue persist.

Don't forget to include your current:

• node version
• npm version
• parse-server version
• any relevant logs (VERBOSE=1 will enable verbose logging)

[kalitas]

is this fixed? it is still happens to me version 2.2.23