Client sessions can become invalid

[ErisDS]

This is related to #8615

This morning, a brand new Ghost blog was setup for the first time at around 8:45am I think. At 1:13pm, @JohnONolan reports being logged out / shown the reauth screen whilst writing a post. Meaning the session didn't last past a few hours. Then #8615 happened, whereby he wasn't able to upload images afterwards.

I have full logs for the blog in question if anyone wants them. Haven't looked at them deeply yet.

[kevinansfield]

I've been trying really hard to replicate this but so far no luck 😞 full logs for the blog could be useful

[kevinansfield]

I've been reviewing again after looking through the server log files. The interesting group of requests appears to be these (paraphrased logs):

11:52:52 - PUT /settings/
11:56:59 - PUT /posts/594b7bfa48abca2476efdd65/?include=tags
11:57:02 - GET /configuration/
11:57:02 - GET /users/me/?include=roles
11:57:02 - GET /settings/?type=blog%2Ctheme%2Cprivate
11:57:03 - POST /authentication/token
11:57:03 - GET /notifications/
11:57:03 - GET /settings/?type=blog%2Ctheme%2Cprivate
11:57:03 - GET /themes/
11:57:14 - PUT /posts/594b7bfa48abca2476efdd65/?include=tags
11:57:15 - GET /configuration/
11:57:15 - GET /users/me/?include=roles
11:57:15 - GET /settings/?type=blog%2Ctheme%2Cprivate
11:57:15 - POST /authentication/token
11:57:15 - GET /notifications/
11:57:15 - GET /settings/?type=blog%2Ctheme%2Cprivate
11:57:15 - GET /themes/
11:57:26 - PUT /posts/594b7bfa48abca2476efdd65/?include=tags
11:57:28 - GET /configuration/
11:57:28 - GET /users/me/?include=roles
11:57:28 - GET /settings/?type=blog%2Ctheme%2Cprivate
11:57:28 - POST /authentication/token
11:57:45 - PUT /posts/594b7bfa48abca2476efdd65/?include=tags
12:01:02 - PUT /posts/594b7bfa48abca2476efdd65/?include=tags
12:01:05 - PUT /posts/594b7bfa48abca2476efdd65/?include=tags
12:12:53 - POST /uploads/ - access denied, client logged out

All requests are for the same user from the same IP address which seems to suggest that multiple tabs were being used and there were at least 3 loads of the admin client (GET /configuration/ only happens at boot).

My current thinking regarding the auth issues relates to this piece of server code that reduces the lifetime of old access tokens to 5 mins each time a new token pair is generated.

I haven't been able to replicate the situation yet but if the access token that a client is using has it's expires shortened on the server due to the generation of new tokens elsewhere then the admin client doesn't know about it and will continue using the soon-to-be-expired token - when the token does expire on the server (5 mins after the token generation) then the admin client will be logged out on the next request

I've tested a lot with multiple tabs, incognito tabs and different browsers but so far my experience has been:

• multiple tabs are kept in sync via the shared local storage
• incognito tabs get their own set of tokens
• different browsers get their own set of tokens

That's not to say the above couldn't break down, if the browser doesn't fire local storage events properly then multiple tabs could go out of sync, I also need to look into how "clients" are determined on the server in order to give incognito tabs/different browsers separate credentials.

Unfortunately the logs strip out the auth headers for security reasons so it's not possible to tell exactly what happened from the logs.

[kevinansfield]

From what I can see and my testing so far I do not believe this is specific to the editor or the uploads endpoint so I'm going to update the issue title to reflect.

My feeling at the moment is that this is an edge case that has appeared due to the frequent token regeneration whilst working in multiple tabs with multiple admin loads/refreshes - it definitely shouldn't happen but it doesn't look like it's a general session bug.

If we don't find exactly why the token expired was used in this case I think there are a couple of avenues to further reduce the likelihood of logout:

1. Remove the shortening of token lifetimes when new tokens are generated.
   • we end up with a lot of long-lived access tokens in the database that are not in use by any clients
2. Implement request retries in the client
   • this would involve intercepting every request and storing them in a queue, if we get a 401 for a request we can attempt to refresh the access token before retrying
   • quite heavy implementation wise, not something we'd want to introduce so close to 1.0

[kevinansfield]

Another potential workaround would be to change the token re-generation on client boot logic so that we only refresh at most once a day - that would prevent the issue with multiple simultaneous tabs and refreshes causing edge cases.

For context the refresh-on-boot behaviour was introduced to ensure that sessions are effectively "infinite" as it means there's a continuous extension of refresh token expiration length.

[kevinansfield]

I think this can be closed for now, there haven't been any further reports since adding the 24 hour token refresh workaround. We can re-open or start a new issue if this rears it's head again.