Edgy edge cases/bugs re: dysfunctional CLPs and Session Token generation (tested in iOS/JS/CloudCode)

[DoneStuffGetting]

Parse v2.2.6

Two things I wanted to discuss:

1. "Saving" a new PFUser behaves weirdly (iOS and JS)
2. "signUp" has a minor security flaw or at least inconsistency (tested on iOS, with CLP locked)
3. Session tokens created even if user isn't created (tested on iOS and JS, with CLP locked and no masterKey used)

Re: "saving" new PFUsers

When saving a new PFUser on iOS, the SDK(?) throws this error:

Caught "NSInternalInconsistencyException" with reason "User cannot be saved unless they are already signed up. Call signUp first."

When saving a new PFUser via Cloud Code, it does not throw that error but simply mimics a "signUp", which creates a session token for the server... in Cloud Code! (actually, read #3 as this may be a bug with the pfuser handling)

For sake of flexibility and consistency (with PFObjects), I think there should be an option to "save" a PFUser without having a session token created, or restricting (iOS) apps to always use PFUser.signUp. There are many use-cases for such a feature, and I feel that it is a meaningless restriction.

Personal use-case: I have some special logic to replace the standard "signUp" flow, which has me creating a PFUser via Cloud Code + MasterKey. But with how the "save" function is behaving, it's creating a session token for the server!

Re: "signUp" security flaw with table fully locked down

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.

Re: Session Tokens out of control

Steps to reproduce (in iOS SDK or Cloud Code):

1. Lockdown User table (and session table if you want.. doesn't change outcome) in Server v2.2.6 Dashboard v1.0.8
2. In iOS or Cloud Code, try to sign a new PFUser up (in Cloud Code, you can use .signUp or .save)
3. Get error response
4. Check dashboard
5. See a new session token

[drew-gross]

Thanks for the reports. I'm going to split this into 3 issues for easier tracking.

[flovilmart]

@drew-gross you can assign to me one or the other or both if you're busy on something else

[DoneStuffGetting]

To summarize (and prioritize) as one issue heavily depends on the server behavior after fixing one bug:


1. False session tokens where PFUser is not created but the token is

2. Fully locked down User table responds with revealing error message when using PFUser.signUp with existing username

3. PFUser.save() should be allowed in iOS to create PFUsers without a session token

4. PFUser.save() in Javascript behaves exactly like signUp (but that may change with bug no.1 fix)

I've plastered test cases in the respective issue tickets.