hoppscotch icon indicating copy to clipboard operation
hoppscotch copied to clipboard

[bug]: In-memory sessions cause logins to fail in load-balanced clusters (401 Unauthorised)

Open dsole opened this issue 2 years ago • 3 comments

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.

  1. Run Hoppscotch locally, configured with an external OAuth identity provider such as Microsoft
  2. 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)
  3. Fully stop and then start your local instance of Hoppscotch
  4. Complete the login flow
  5. 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

dsole avatar Sep 05 '23 05:09 dsole

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

dsole avatar Sep 05 '23 05:09 dsole

Hi! Is there any update on this since I am facing the same issue.

nannan-motorq avatar Nov 13 '24 06:11 nannan-motorq

Same issue here, when i set 2 replicas or more, backend callback return 401.

CorentinRegnier avatar Feb 21 '25 16:02 CorentinRegnier