starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 16:55:59 +03:00

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

New issue

Open

opened 2026-03-16 18:34:00 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 18:34:00 +03:00

Owner

Originally created by @dsole on GitHub (Sep 5, 2023).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/3315

Is there an existing issue for this?

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

Originally created by @dsole on GitHub (Sep 5, 2023). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/3315 ### 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](https://www.npmjs.com/package/express-session) to hold some session state during the authentication flow. I believe this is required by the [PassportJS](https://www.passportjs.org/) 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](https://github.com/expressjs/session#store) > **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

kerem added the

bug

need testing

self-host

labels

2026-03-16 18:34:00 +03:00

kerem commented

2026-03-16 18:34:12 +03:00

Author

Owner

@dsole commented on GitHub (Sep 5, 2023):

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 commented on GitHub (Sep 5, 2023): 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

kerem commented

2026-03-16 18:34:17 +03:00

Author

Owner

@nannan-motorq commented on GitHub (Nov 13, 2024):

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

@nannan-motorq commented on GitHub (Nov 13, 2024): Hi! Is there any update on this since I am facing the same issue.

kerem commented

2026-03-16 18:34:22 +03:00

Author

Owner

@CorentinRegnier commented on GitHub (Feb 21, 2025):

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

@CorentinRegnier commented on GitHub (Feb 21, 2025): Same issue here, when i set 2 replicas or more, backend callback return 401.

kerem commented

2026-03-16 18:34:27 +03:00

Author

Owner

@spagno commented on GitHub (Jan 19, 2026):

Some issue here with google oauth. As workaround I configured the ingress with a cookie sticky session (self-hosted on kubernetes). The real fix could be to make redis mandatory and move the sessions there

@spagno commented on GitHub (Jan 19, 2026): Some issue here with google oauth. As workaround I configured the ingress with a cookie sticky session (self-hosted on kubernetes). The real fix could be to make redis mandatory and move the sessions there

kerem referenced this issue

2026-03-17 00:42:46 +03:00

[PR #1100] [CLOSED] Bump jest from 26.4.0 to 26.4.1 #3065