[bug]: In-memory sessions cause logins to fail in load-balanced clusters (401 Unauthorised)
Is there an existing issue for this?
- [X] I have searched the existing issues
Current behavior
I am using the Microsoft authentication method but in theory this could be affecting the others.
The backend service is using express-session to hold some session state during the authentication flow. I believe this is required by the PassportJS library that is used to perform the OAuth authorisation flow.
However the express-session is not configured with a session storage provider via the store parameter and so defaults to in-memory sessions. As per their documentation
store The session store instance, defaults to a new MemoryStore instance.
If the user lands on a different node in the cluster to process the OAuth code flow code callback, the session cannot be resolved and the Hoppscotch backend returns the error
{
"statusCode": 401,
"message": "Unauthorized"
}
Steps to reproduce
You can verify this by running the system in a multi-node, load balanced cluster such as Kubernetes with multiple replicas of the pod.
However a reliable way to replicate it locally is to stop and then restart the Hoppscotch backend server during the authentication phase, before the browser returns from the identity provider back to Hoppscotch to complete the login.
- Run Hoppscotch locally, configured with an external OAuth identity provider such as Microsoft
- Open your local Hoppscotch in the browser and go through the login steps to stop at the external identity provider's page ( such as their username page)
- Fully stop and then start your local instance of Hoppscotch
- Complete the login flow
- Note the error page when you hit the backend's callback page eg http://localhost:3170/v1/auth/microsoft/callback
Environment
Production
Version
Self-hosted
A possible solution would be to use a Postgres-backed session store using the database that is already available. However I suggest the session store could be configurable so that alternate stores could be used such as a HA distributed store such as etcd or Redis
Hi! Is there any update on this since I am facing the same issue.
Same issue here, when i set 2 replicas or more, backend callback return 401.