Regression in parse server 2.3.3 getting {"code":209,"message":"invalid session token"} with master key sometimes

[jbpringuey]

Issue Description

Version 2.3.3 created lot of production issues for us. It seems that some changes happened around how sessions are managed and users are cached.
One of the big problems is that our jobs started failing with {"code":209,"message":"invalid session token"} even if we use master key . Another problem is that one of our public cloud function which also use master key started failing with that same error also.

Rolling back to 2.3.2 fixes our issues.

Steps to reproduce

Write a job or a cloud function which uses masterKey and it will randomly (Have not had the chance yet to find exact steps) to fail.

Expected Results

Jobs using Master key in all queries and API should not throw invalid session token

Actual Outcome

Jobs using Master key in all queries and API should not throw invalid session token

Environment Setup

• Server

  • parse-server version : 2.3.3
  • Operating System: Heroku Dyno (Linux I beleive)
  • Localhost or remote server? Heroku

• Database

  • MongoDB version: 3.0.11
  • Storage engine: MMAPv1
  • Hardware: 40 GB SSD on AWS
  • Localhost or remote server? Heroku

Logs/Trace

An error happened during execution of mainJob: {"code":209,"message":"invalid session token"}

[flovilmart]

Were you by any chance using Parse.Cloud.useMasterKey()?

[jbpringuey]

@flovilmart no we are using query.find({useMasterKey: true}) all over the code

[natanrolnik]

@jbpringuey can you please share part of your code, some logs, or a bit more information?

[dstarke]

I'm seeing something similar. At some point, a bunch of requests made from cloud code start failing with invalid session token errors. I haven't figured out how to reproduce it yet, but I've been looking at it.

However, in my case, every time I've seen this error so far, it has either included or been preceded by calls to code that calls fetch(), find(), first(), each(), or save() on publicly readable and writable objects without specifying either a session token or useMasterKey:true in the options. That code usually works, and then it seems something happens that makes things start failing.

Clearly there were some issues in the code I'm working on, and I've now fixed all those calls by supplying a session token or master key, but I don't think the behavior of that code should suddenly change in this way. I hope this additional information can help track down the problem.

[flovilmart]

@jbpringuey can you provide code/objects examples that makes those calls fail?

[jbpringuey]

@flovilmart I am working on repro steps right now, it may have to do with user caching. I am also seeing the issue now in the prior version but not as frequent so it may be a bug that has always been there.

The only thing that has changed recently on our side is the # of users/sessions which has increased and we are still using local caching instead of redis because the redis implementation would slow us down because it always deserialize from redis and does not cache locally.

here is some sample code which is wrapped around a parse function and sometimes runs into {"code":209,"message":"invalid session token"} :

         `         var orgQuery = new Parse.Query("CoolrOrganization");
		orgQuery.equalTo("name", userCompanyName);
		return orgQuery.find({useMasterKey: true}).then(function (results) {
			if (results.length > 0) {
				var excludedEmails = results[0].get("excludedEmails");
				if (!_.isUndefined(excludedEmails) && excludedEmails.length > 0) {
					if (_.contains(excludedEmails, email)) {
						response.error("BlackListedEmail");
                                                    return Parse.Promise.error("BlackListedEmail");
					}
				}
			}
			return Parse.Promise.as();
	         });`

[flovilmart]

With useMasterKey, there should never be a invalidSesssionToken yielded. That's most likely a bug

[maximeloizeau]

I didn't have time to recreate a proper ticket for the issue I raised a 2 weeks ago. This issue may be related to it #3471

In short, the Parse JS SDK is using the last user token it cached to make a request if no session token is provided.

[dstarke]

@jbpringuey Are you using LiveQuery? One thing I just noticed is that the LiveQuery code is calling enableUnsafeCurrentUser(). This, along to a call to become(sessionToken) (which would fail if unsafeCurrentUser were disabled) in LiveQuery's session token cache, is (I think) how user information is getting cached when it should not be.

Since the comments in the code, along with the method name, indicate that this method is unsafe on the server, the LiveQuery code should not be doing this.

[dstarke]

The LiveQuery code also had a call to Query.find() that was not issued with the master key. The combination of that with the issue I described above could have been causing these problems. I've created a pull request that fixes these issues.

[jbpringuey]

@flovilmart @dstarke I am not using so I am not sure this is a dup of 3525 . @maximeloizeau can you please give more details on what you think this is and point to the code that is causing the issue ? It seems much more like what I am facing. I was planning to do some debugging next week. thanks !

[flovilmart]

@jbpringuey that would help if you could get the logs with running with VERBOSE=1, so we can make sure what's causing the issue.