"cannot modify user" and request.user undefined on 2.2.5 & 2.2.6

[refre5h]

• You've met the prerequisites.
• You're running the latest version of Parse Server.
• You've searched through existing issues. Chances are that your issue has been reported or resolved before.

Environment Setup

parse-server 2.2.4 + heroku + mlab
parse-server 2.2.5 + heroku + mlab
parse-server 2.2.6 + heroku + mlab

The issues

After updating to 2.2.5 / 2.2.6, 2 new errors occurred. Reverting back to 2.2.4 solves them. We also didn't have these problems in earlier parse-server versions.

Issue 1:
When writing to the _User object fIqh5VlbUy (logged in as that same user fIqh5VlbUy), get this error cannot modify user fIqh5VlbUy. Note: other users are also getting the error, not just fIqh5VlbUy.

Issue 2:
We have cloud functions that have these lines of codes:

var user = request.user;
if (!user) return response.error("You are not a user.");

All these functions are returning the not a user error. console.log(request.user) gives undefined.

Steps to reproduce

Update from parse-server from 2.2.4 to 2.2.5.

[drew-gross]

We have lots of passing test cases that cover these features. Can you post some code that reliably reproduces your issue? Ideally as a test case we can add to our test suite.

[refre5h]

@drew-gross Thanks for the comment. I'm new to the programing so still figuring out how to write a test case. That's why we picked Parse in the first place.

Anyways, after digging more into this, we found that when the iOS app first launches, the first couple functions (about 3 to 5) are being called with the correct request.user, but subsequent calls (same and different functions) within the same session will experience the error related to the undefined request.user.

Here's an example function we have that runs and returns fine when the app initially launches, but start returning "you are not a user" error just a couple seconds after the app launches, within the same session.

Parse.Cloud.define("getGlobalConfig", function(request, response) {
    var user = request.user;
    if (!user) return response.error("you are not a user"); // This error starts appearing on 2.2.5

    Parse.Config.get().then(function(config){
        response.success(config.attributes);
    }, function(error){
        response.error(error);
    })
})

At this point, we are not sure if it's a client issue or not. But if it is, I think we should have experienced this before 2.2.5 as nothing else was changed except for upgrading the server version. We will dig more into this, but I hope the info above would help you find the possible issue on the server side.

[drew-gross]

It's very difficult to debug sporadic issues like that. Have you checked the requests being sent by the iOS app to make sure the request contents are the same?

[refre5h]

I logged the request the server received in both 2.2.4 and 2.2.5. Same call by the same iOS client twice in each server version, about 1 min apart. The difference is, both 2.2.4's requests have the user object, whereas only the first request in 2.2.5 has it, the second doesn't.

console.log({
    time: new Date(),
    request: request
});

2.2.4

2016-04-07T20:08:40.852428+00:00 app[web.1]: { time: Thu Apr 07 2016 20:08:40 GMT+0000 (UTC),
2016-04-07T20:08:40.852462+00:00 app[web.1]:   request: 
2016-04-07T20:08:40.852464+00:00 app[web.1]:    { params: { id: 'gTGJZHahwA', items: [Object] },
2016-04-07T20:08:40.852465+00:00 app[web.1]:      master: false,
2016-04-07T20:08:40.852466+00:00 app[web.1]:      user: ParseUser { _objCount: 0, className: '_User', id: 'gTGJZHahwA' },
2016-04-07T20:08:40.852466+00:00 app[web.1]:      installationId: '1168c382-cd54-4bf9-82ed-e641790974a8' } }

2016-04-07T20:09:48.983758+00:00 app[web.1]: { time: Thu Apr 07 2016 20:09:48 GMT+0000 (UTC),
2016-04-07T20:09:48.983792+00:00 app[web.1]:   request: 
2016-04-07T20:09:48.983795+00:00 app[web.1]:    { params: { id: 'gTGJZHahwA', items: [Object] },
2016-04-07T20:09:48.983796+00:00 app[web.1]:      master: false,
2016-04-07T20:09:48.983798+00:00 app[web.1]:      user: ParseUser { _objCount: 0, className: '_User', id: 'gTGJZHahwA' },
2016-04-07T20:09:48.983798+00:00 app[web.1]:      installationId: '1168c382-cd54-4bf9-82ed-e641790974a8' } }

2.2.5

2016-04-07T20:12:50.822537+00:00 app[web.1]: { time: Thu Apr 07 2016 20:12:50 GMT+0000 (UTC),
2016-04-07T20:12:50.822578+00:00 app[web.1]:   request: 
2016-04-07T20:12:50.822579+00:00 app[web.1]:    { params: { id: 'gTGJZHahwA', items: [Object] },
2016-04-07T20:12:50.822580+00:00 app[web.1]:      master: false,
2016-04-07T20:12:50.822580+00:00 app[web.1]:      user: ParseUser { _objCount: 12, className: '_User', id: 'gTGJZHahwA' },
2016-04-07T20:12:50.822581+00:00 app[web.1]:      installationId: '1168c382-cd54-4bf9-82ed-e641790974a8' } }

2016-04-07T20:13:48.432703+00:00 app[web.1]: { time: Thu Apr 07 2016 20:13:48 GMT+0000 (UTC),
2016-04-07T20:13:48.432713+00:00 app[web.1]:   request: 
2016-04-07T20:13:48.432714+00:00 app[web.1]:    { params: { id: 'gTGJZHahwA', items: [Object] },
2016-04-07T20:13:48.432715+00:00 app[web.1]:      master: false,
2016-04-07T20:13:48.432715+00:00 app[web.1]:      user: undefined,
2016-04-07T20:13:48.432716+00:00 app[web.1]:      installationId: '1168c382-cd54-4bf9-82ed-e641790974a8' } }

[tanmays]

Run parver server locally with VERBOSE=1 npm start command and send the entire request-response log. Make sure the request contains a valid session token. User undefined issue usually occurs when session token is missing or invalid.

You can test a parse sever locally with iOS using something like ngrok.

[refre5h]

@tanmays Here's the log. I noticed the second call in 2.2.5 has a different x-parse-session-token. The first call in 2.2.5 and both calls in 2.2.4 all have the same token. Does this look like a client or server issue?

// 2.2.4. 1st call. No error.
verbose: POST /parse/functions/getTodos { host: 'localhost:1337',
  'x-parse-client-version': 'i1.13.0',
  accept: '*/*',
  'x-parse-session-token': 'r:8e00bcf342c7a1bff76919b5e613cb3a',    <<< CORRECT
  'x-parse-application-id': 'myAppId',
  'x-parse-client-key': 'myClientKey',
  'x-parse-installation-id': 'd79ec1b6-8cc6-418b-a076-cf46c04d06b3',
  'x-parse-os-version': '9.3 (15E65)',
  'accept-language': 'en-us',
  'accept-encoding': 'gzip, deflate',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '82',
  'user-agent': 'myapp/4 CFNetwork/758.3.15 Darwin/15.4.0',
  connection: 'keep-alive',
  'x-parse-app-build-version': '4',
  'x-parse-app-display-version': '0.2.1' } {
  "id": "gTGJZHahwA",
  "items": [
    "chat",
    "application",
    "request",
    "rating",
    "directChat"
  ]
}

// 2.2.4. 2nd call in the same session. No error.
verbose: POST /parse/functions/getTodos { host: 'localhost:1337',
  'x-parse-client-version': 'i1.13.0',
  accept: '*/*',
  'x-parse-session-token': 'r:8e00bcf342c7a1bff76919b5e613cb3a',    <<< CORRECT
  'x-parse-application-id': 'myAppId',
  'x-parse-client-key': 'myClientKey',
  'x-parse-installation-id': 'd79ec1b6-8cc6-418b-a076-cf46c04d06b3',
  'x-parse-os-version': '9.3 (15E65)',
  'accept-language': 'en-us',
  'accept-encoding': 'gzip, deflate',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '82',
  'user-agent': 'myapp/4 CFNetwork/758.3.15 Darwin/15.4.0',
  connection: 'keep-alive',
  'x-parse-app-build-version': '4',
  'x-parse-app-display-version': '0.2.1' } {
  "id": "gTGJZHahwA",
  "items": [
    "chat",
    "application",
    "request",
    "rating",
    "directChat"
  ]
}

// 2.2.5. 1st call. No error.
verbose: POST /parse/functions/getTodos { host: 'localhost:1337',
  'x-parse-client-version': 'i1.13.0',
  accept: '*/*',
  'x-parse-session-token': 'r:8e00bcf342c7a1bff76919b5e613cb3a',    <<< CORRECT
  'x-parse-application-id': 'myAppId',
  'x-parse-client-key': 'myClientKey',
  'x-parse-installation-id': 'd79ec1b6-8cc6-418b-a076-cf46c04d06b3',
  'x-parse-os-version': '9.3 (15E65)',
  'accept-language': 'en-us',
  'accept-encoding': 'gzip, deflate',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '82',
  'user-agent': 'myapp/4 CFNetwork/758.3.15 Darwin/15.4.0',
  connection: 'keep-alive',
  'x-parse-app-build-version': '4',
  'x-parse-app-display-version': '0.2.1' } {
  "id": "gTGJZHahwA",
  "items": [
    "chat",
    "application",
    "request",
    "rating",
    "directChat"
  ]
}

// 2.2.5. 2nd call in the same session. ERROR.
verbose: POST /parse/functions/getTodos { host: 'localhost:1337',
  'x-parse-client-version': 'i1.13.0',
  accept: '*/*',
  'x-parse-session-token': 'srntcKyWsoxzcNbXpdlPXtm6u',    <<< INCORRECT
  'x-parse-application-id': 'myAppId',
  'x-parse-client-key': 'myClientKey',
  'x-parse-installation-id': 'd79ec1b6-8cc6-418b-a076-cf46c04d06b3',
  'x-parse-os-version': '9.3 (15E65)',
  'accept-language': 'en-us',
  'accept-encoding': 'gzip, deflate',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '82',
  'user-agent': 'myapp/4 CFNetwork/758.3.15 Darwin/15.4.0',
  connection: 'keep-alive',
  'x-parse-app-build-version': '4',
  'x-parse-app-display-version': '0.2.1' } {
  "id": "gTGJZHahwA",
  "items": [
    "chat",
    "application",
    "request",
    "rating",
    "directChat"
  ]
}

[drew-gross]

Given that the server is responding with the exact same thing in both versions, I think this must be a client error. It's possible that a performance improvement in Parse Server exposed a race condition in your client that was previously hidden due to a longer response time or something like that, and thats why 2.2.4 appears to work. It might be a bug in iOS SDK, but since the client is in fact sending an invalid session, it can't be a bug in the server.

[refre5h]

Just some update: new users created post server migration don't have this issue. The users who had been migrated from the hosted parse are having this issue. So we ended up wiping the whole user db.

[flovilmart]

@refre5h did you had revocable sessions enabled? seems that the INCORRECT token is a non revocable session token.

[refre5h]

@flovilmart the ios client does not explicitly set this enabled, i.e. it doesn't [PFUser enableRevocableSessionInBackground]. I thought Parse apps created after March 25, 2015 have this enabled by default? Now that there are only new users in the db, should we enable it?

[flovilmart]

Yeah, that's a good idea as parse-server don't support legacy sessions

[daj17]

I have this bug too. Absolutely the most annoying parse bug ever. Persnickity; there isn't even method to the madness. I can't save a username and password once logged in without getting a modification error. And yet I can alter ever other field at will. After setting the username and password--I do this AFTER loggining in-- I get: "error: Error Domain=Parse Code=206 "cannot modify user xxxxxx". It's really hard for me to 'program' by anticipating race condition bugs in the SDK...Not really sure what to do... The reason I want to set the username and password is so I can implement an instantaneous cached login upon launch. I don't want the user to have to press the LOGIN WITH FACEBOOK button every time to app boots up. If you have suggestions please tell me. Thank you