Managing Session Issues - Parse error: Invalid session token

[rizzla22]

Hosting: locally on OSX running parse server 3.5.0

I am having massive issues with sessions on my cloud infrastructure, when a device tries to make a request with a session that does not exist it cripples the entire server. with the following error

[1] error: Parse error: Invalid session token {"code":209,"stack":"Error: Invalid session token\n    at Object.getAuthForSessionToken (.../node_modules/parse-server/lib/Auth.js:114:11)\n    at process._tickCallback (internal/process/next_tick.js:68:7)"}

Is there anyway to validate that a session exists before killing the server with an error, been trying to use express middleware but I cant seem to find an entry point to add any code for doing checks, also I have read the docs and found this https://docs.parseplatform.org/js/guide/#handling-invalid-session-token-error

however I also cannot seem to locate the entry point in the rest api that causes this error, I have removed all code from my main.ts file so there is only 1 rest item being hit but I still see the invalid session error showing up...

Whats weird is that I can do a CURL request with no session headers etc and it goes through fine, could something on the client side be causing this error and pushing it to the server, or is there an entry point that processes the request before sending to the cloud function handler, this is what I need to find and modify with a session checker.

On the client side I am using a service which calls the cloud functions, perhaps the session is somehow contained in this Parse.Cloud.run and it fails here within the app rather than over on the remote server ? could this be the case

    async cloud(cloudFunctionName: string, params?: any): Promise<any> {
        try {
            const result = await Parse.Cloud.run(cloudFunctionName, params)
            return result
        } catch (error) {
            throw error
        }
    }

any ideas ?

async function loggedUser(sessionToken: string) {
  const loggedUserSessionQuery = new Parse.Query(Parse.Session);
  loggedUserSessionQuery.equalTo('sessionToken', sessionToken);
  loggedUserSessionQuery.include('user');

  const loggedUserSession = await loggedUserSessionQuery.first({
    sessionToken
  });

  if (!loggedUserSession) {
    throw new Error('Invalid session token.');
  }

  return loggedUserSession.get('user');
}

or this

const myMiddleware = function (req, res, next) {
    const json = res.json;
    res.json = function (object) {
        if (object.code == Parse.Error.INVALID_SESSION_TOKEN) {
            // get the session token
            const token = req.headers['x-parse-session-token'];
            // Invalid token, do something
        }
        // Forward the response
        json.call(res, object);
    }
    next()
}

related issues:
#5209
#618
#4395
https://stackoverflow.com/questions/50477035/parse-server-capture-bad-session-token-requests/50488603

[rizzla22]

On further investigation I find that even calling Parse.Session.current() will result in an error on the server side, in a cloud environment like Google App Engine this is enough to totally take my instance offline. Can we not just return a simple boolean value rather than a destructive error ?

[davimacedo]

@rizzla22 it is really strange behavior. The invalid session token should be logged in Parse Server logs and returned to the client. But it should not break the Parse Server process. Can you please share more details about how you are running Parse Server?

[mman]

@rizzla22 the invalid session token message is harmless and can happen for example when a user changes password and all existing session tokens for the user are deleted. An app that talks to the parse server later with expired session token will generate the invalid session token message. It definitely will not kill the server. Please post more logs or backtraces.

[REPTILEHAUS]

I experience this. Im not sure what the adverse affects are but I do notice that when this happens in a Google App Engine environment that there is usually an preceeded by a invalid session

[dplewis]

@REPTILEHAUS does your server crash?

We should document installationId and what it means.

What info should be included with invalid session for debugging that isn’t too sensitive.

Similar too #4330