Wrongly deleted sessions

[SebC99]

Issue Description

We do log a big number of INVALID_SESSION_TOKEN errors for our users, appearing without any apparent logic: sessions are not expired, the user hasn't changed the password, sometimes it happens multiple times in the same day, and we can't figure out why.
Is there any way for us to better detect the reason for this?
Are we the only one with this weird behavior?

I know there's multiple places in the code where Sessions are deleted (or session caches) but I can't see why it could explain that.

Any help would be appreciated :)

[mtrezza]

• Is there any pattern when you see these logs?
• Are you only getting these errors recently?

[SebC99]

Unfortunately not, we can't find any pattern
It's been a while, but maybe slightly more during last the last weeks, but we also had an increase of users coming back after a few weeks off because of the covid. But with a 1 year session token, that should not happen. We even have cases with users being disconnected each day (through FB login)

[dplewis]

@SebC99 @mtrezza Can I add you to the Parse Team? I would have sent an email sorry about that.

[mtrezza]

@dplewis Sure, please go ahead.

@SebC99 Could it be some external reason? I am thinking of an iOS setting that uninstalls apps automatically when they are not used for some time, and then restores them from cloud. Or auto-backup on Android, see parse-community/Parse-SDK-Android#970 (comment). If a user opens the app again after 2 months, maybe it gets restored and that causes some issues, hence you see more errors after covid?

[SebC99]

@dplewis not sure it was addressed to me, but if so yes for sure

@mtrezza We have seen the same on test devices where we know for sure this iOS setting is not activated... So I'm guessing it's not linked.
It seems to be somewhat proportional with the number of devices used by an account, but it's not even sure.

BTW we also know that we have an issue each time a user restore its phone as Parse always fails to restore the currentUser (we have activated the anonymous account, so it's hard to detect when this occurs). But I think that's an issue with Parse iOS SDK, and it's another subject.

[mtrezza]

I guess the first step would be determining whether the issue is server or client side. The error can be thrown in many different places on the server, can you tell from the stack trace where it is thrown?

[SebC99]

I know. A hint is that it seems to occur on both iOS and Android apps, so it seems to be server side.
But as we are 90% iOS, it's much more frequent on iOS and it's hard to be sure.

On client side, we only see the 209 Invalid Session Token error, but with AWS X-Ray we were able to see more details, and it seems it's always this trace:

Error: Invalid session token
at Object.getAuthForSessionToken (/var/app/current/node_modules/parse-server/lib/Auth.js:106)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:97)

Which is why I supposed it was an issue with wrongly deleted sessions.

[mtrezza]

/lib/Auth.js:106

I assume thats this?

parse-server/src/Auth.js

Lines 104 to 109 in de79b70

	if (results.length !== 1 || !results[0]['user']) {
	throw new Parse.Error(
	Parse.Error.INVALID_SESSION_TOKEN,
	'Invalid session token'
	);
	}

[SebC99]

I think so...
And we have a unique index, and we always have the 'user' field, so it's really because of a deletion of the session object... but why?

[mtrezza]

That really seems like either the session was removed or the token was incorrect. Did you check whether the requests may be malicious, maybe trying to brute force the session token? See #6755

[SebC99]

We don't see any weird requests, and it also happens with our own devices / sessions.
We even found cases where all the sessions token of one user were removed without reasons.

[mtrezza]

Have you set a TTL index on the session collection expireAt field?

[mtrezza]

We even found cases where all the sessions token of one user were removed without reasons.

Interesting that you say "all the session tokens". There should ever only be one session object per user per installation. If all session objects of the user of different installations are deleted, that could point to an issue in your custom code.

If I understand this correctly, before a new session object is created, all existing sessions objects of that user/installation combination are destroyed:

parse-server/src/RestWrite.js

Line 975 in 288e746

RestWrite.prototype.destroyDuplicatedSessions = function() {

Interestingly, this is executed before runDatabaseOperation which runs the actual query. If creating the new session fails for some reason, all existing sessions would already be deleted and there would be not any session object left for that user/installation combination, if I understood the flow correctly. The new session is actually created before that in handleSession.

[SebC99]

No TTL index I think, and we have a lots of old session token, so I guess it wouldn't be the case with a TTL index. (It could be nice to have one haha)
All sessions tokens because or tests accounts are used on many devices, and we often logout/login from these accounts, and they are also used on simulators... so they do have lots of installationId :)

But the issue of deleted sessions is for all users.

[mtrezza]

(It could be nice to have one haha)

I added functionality to build a TTL index in #6748 so someone could add that feature easily after merge

All sessions tokens because or tests accounts are used on many devices, and we often logout/login from these accounts, and they are also used on simulators... so they do have lots of installationId :)

I cannot think of a debugging scenario in which a session would be deleted while it is still in use on another device, given that each device has its own installation ID. I also have never experienced that when debugging. Maybe the issue is related to your custom code where you manipulate sessions / installations / users?

Could it be that you try to execute some server calls on the client after the user logged out? I think that would cause the same error?