Bug in saving new users via Cloud Code

[drew-gross]

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!

Ref #1490

[DoneStuffGetting]

Session token bug --> #1497

[flovilmart]

Just investigate that one and:

let user = new Parse.User()
user.save();

// and
let user  = new Parse.Object('_Users')
user.save();

// and
let user = new Parse.User()
user.signUp("username","password")

all 3 make calls to the /users endpoints, so we can't really infer anything from that.

Another option would be to skip the session creation when using { useMasterKey: true }.
That seems reasonable as I can't think of a good reason to want to create a sessionToken as master.

[DoneStuffGetting]

Another option would be to skip the session creation when using { useMasterKey: true }.
That seems reasonable as I can't think of a good reason to want to create a sessionToken as master.

That sounds good. Would it apply to all SDKs that are connected with the masterkey as well?

[flovilmart]

Yeah REST, node etc...

[flovilmart]

@drew-gross is that reasonable? Or maybe we can check the request headers and make sure we don't generate a Session Token for Cloud Code, nor nodejs, nor REST etc... I tend to think the masterKey is a workaround.

We could use the User-Agent: https://github.com/ParsePlatform/Parse-SDK-JS/blob/master/src/RESTController.js#L129

[drew-gross]

Checking IS_NODE seems like a good solution. Sometime you want to make requests as a specific user even in Cloud Code so having that work as expected and not create session tokens is important.

[flovilmart]

ok so I'll check for the User-Agent somewhere

[flovilmart]

@drew-gross once again, we face an issue with parse.js being single minded. I overrode the InstallationsController to return 'parse-server' as the installationId (as it is in regular parse.com's cloud code). The problem being that it breaks all of our tests.

we could overcome that maybe by running the cloud endpoint in their own VM...

[drew-gross]

Which tests does it break and why? If parse-server is what Parse.com returns, we should try to do the same thing.

[pbmarcano]

Is there a work around for this I can write myself? I am running an app that uses a slightly modified version of AnyPhone and all my users are created and log in through Cloud Code.

This is the final barrier between my full migration off of parse.com.