starred/hoppscotch

Fork 0

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

[GH-ISSUE #4379] [feature]: store user sessions in DB #1599

New issue

Closed

opened 2026-03-16 21:00:55 +03:00 by kerem · 12 comments

kerem commented

2026-03-16 21:00:55 +03:00

Owner

Originally created by @RaHehl on GitHub (Sep 26, 2024).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4379

Is there an existing issue for this?

I have searched the existing issues

Summary

We would like to use pod scaling, as far as I understand it would be necessary for all (api) pods to have the same session information, so the best solution would probably be to store the sessions in the database.

Maybe this can be easily solved: https://github.com/kleydon/prisma-session-store

Why should this be worked on?

Makes Hoppscotch more enterprise-ready

Originally created by @RaHehl on GitHub (Sep 26, 2024). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4379 ### Is there an existing issue for this? - [X] I have searched the existing issues ### Summary We would like to use pod scaling, as far as I understand it would be necessary for all (api) pods to have the same session information, so the best solution would probably be to store the sessions in the database. Maybe this can be easily solved: https://github.com/kleydon/prisma-session-store ### Why should this be worked on? Makes Hoppscotch more enterprise-ready

kerem

2026-03-16 21:00:55 +03:00

closed this issue
added the
feature
label

kerem commented

2026-03-16 21:01:11 +03:00

Author

Owner

@sah246ir commented on GitHub (Sep 29, 2024):

i am really interested in working on this issue.

@sah246ir commented on GitHub (Sep 29, 2024): i am really interested in working on this issue.

kerem commented

2026-03-16 21:01:16 +03:00

Author

Owner

@yashs33244 commented on GitHub (Oct 7, 2024):

Hey there, if no one's working on this, can i be assigned this issue? Thank you!

@yashs33244 commented on GitHub (Oct 7, 2024): Hey there, if no one's working on this, can i be assigned this issue? Thank you!

kerem commented

2026-03-16 21:01:21 +03:00

Author

Owner

@iRittikSharma commented on GitHub (Oct 8, 2024):

Hi @RaHehl I would like to work on this issue. Could You please assign it to me

@iRittikSharma commented on GitHub (Oct 8, 2024): Hi @RaHehl I would like to work on this issue. Could You please assign it to me

kerem commented

2026-03-16 21:01:26 +03:00

Author

Owner

@RaHehl commented on GitHub (Oct 8, 2024):

Hi, I'm just the creator of the "issue". From what I understand, this should be assigned by someone from the Hopscotch team? @liyasthomas

@RaHehl commented on GitHub (Oct 8, 2024): Hi, I'm just the creator of the "issue". From what I understand, this should be assigned by someone from the Hopscotch team? @liyasthomas

kerem commented

2026-03-16 21:01:31 +03:00

Author

Owner

@liyasthomas commented on GitHub (Oct 8, 2024):

Hi @iRittikSharma, do you have a proposal for the implementation. I'd love to discuss different possibilities of the implementation with Hoppscotch development team.

Feel free to open up a draft PR if you've already started working on it.

@liyasthomas commented on GitHub (Oct 8, 2024): Hi @iRittikSharma, do you have a proposal for the implementation. I'd love to discuss different possibilities of the implementation with Hoppscotch development team. Feel free to open up a draft PR if you've already started working on it.

kerem commented

2026-03-16 21:01:36 +03:00

Author

Owner

@sah246ir commented on GitHub (Oct 9, 2024):

here's my workflow for the issue

firstly we can create a database table/collection to store the session id's and a few more parameters if required, this can be done from scratch on login or using the prisma-session-store library.
secondly we will store the session id as a secure http only cookie on the client side which will be attached to every request from the client.
thirdly we can create or modify existing middlewares to validate authentication.
lastly we can create or modify an endpoint to retrieve authentication status. the client will ping this route once on login to confirm the auth.

p.s @liyasthomas it would be better if you could assign it to someone so that there is only one person responsible for the task.

i would love to work on this too.

@sah246ir commented on GitHub (Oct 9, 2024): here's my workflow for the issue - firstly we can create a database table/collection to store the session id's and a few more parameters if required, this can be done from scratch on login or using the prisma-session-store library. - secondly we will store the session id as a secure http only cookie on the client side which will be attached to every request from the client. - thirdly we can create or modify existing middlewares to validate authentication. - lastly we can create or modify an endpoint to retrieve authentication status. the client will ping this route once on login to confirm the auth. p.s @liyasthomas it would be better if you could assign it to someone so that there is only one person responsible for the task. i would love to work on this too.

kerem commented

2026-03-16 21:01:41 +03:00

Author

Owner

@liyasthomas commented on GitHub (Oct 9, 2024):

Looping in @AndrewBastin.

@liyasthomas commented on GitHub (Oct 9, 2024): Looping in @AndrewBastin.

kerem commented

2026-03-16 21:01:46 +03:00

Author

Owner

@balub commented on GitHub (Oct 9, 2024):

Hey 👋 seems interesting, I can work on this.

@balub commented on GitHub (Oct 9, 2024): Hey 👋 seems interesting, I can work on this.

kerem commented

2026-03-16 21:01:51 +03:00

Author

Owner

@balub commented on GitHub (Oct 9, 2024):

@RaHehl correct me if I am wrong here, but we essentially need to implement basic session storage now, where the session info is stored in our postgres?

@balub commented on GitHub (Oct 9, 2024): @RaHehl correct me if I am wrong here, but we essentially need to implement basic session storage now, where the session info is stored in our postgres?

kerem commented

2026-03-16 21:01:56 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Oct 9, 2024):

@RaHehl The self-hosted backend server uses JWTs to encode session information, so I am kinda confused by the session point you are raising here, the authorisation is done by reading the token, not across the DB or a session state that we maintain.

The challenge to pod scaling (horizontal scaling) implementation is actually related to mostly regarding two things.

Data Subscriptions - The API server talks over GraphQL to listen to changes happening to workspaces, this is how realtime updates of collections and environments work on Hoppscotch. When you have multiple backend instances running, updates to the data could be accessing in one server and not the other.
Configuration Changes - The admin dashboard allows you to set configuration updates that needs the server to restart. Notifying other instances to do that is a challenge as well.

Support for horizontal scaling is something we are working on and we will aim to ship it by the end of this month for the 2024.10 release cycle.

@RaHehl, can you confirm that you meant this issue to raise support for horizontal scaling (ability to have multiple instances of AIO/Backend containers to handle scaled loads ?) and not something else ?

@AndrewBastin commented on GitHub (Oct 9, 2024): @RaHehl The self-hosted backend server uses JWTs to encode session information, so I am kinda confused by the session point you are raising here, the authorisation is done by reading the token, not across the DB or a session state that we maintain. The challenge to pod scaling (horizontal scaling) implementation is actually related to mostly regarding two things. 1. Data Subscriptions - The API server talks over GraphQL to listen to changes happening to workspaces, this is how realtime updates of collections and environments work on Hoppscotch. When you have multiple backend instances running, updates to the data could be accessing in one server and not the other. 2. Configuration Changes - The admin dashboard allows you to set configuration updates that needs the server to restart. Notifying other instances to do that is a challenge as well. Support for horizontal scaling is something we are working on and we will aim to ship it by the end of this month for the 2024.10 release cycle. @RaHehl, can you confirm that you meant this issue to raise support for horizontal scaling (ability to have multiple instances of AIO/Backend containers to handle scaled loads ?) and not something else ?

kerem commented

2026-03-16 21:02:01 +03:00

Author

Owner

@RaHehl commented on GitHub (Oct 14, 2024):

@AndrewBastin yes i can confirm it's for horizontal scaling, scaling loads and maybe version upgrades without downtime.

From a security perspective I would like to understand the jwt theme better

Am I seeing this correctly? The API issues a JWT token with the user ID and signs the whole thing. And when the client uses this signed token, is it the stateless authentication for the backend?

@RaHehl commented on GitHub (Oct 14, 2024): @AndrewBastin yes i can confirm it's for horizontal scaling, scaling loads and maybe version upgrades without downtime. From a security perspective I would like to understand the jwt theme better Am I seeing this correctly? The API issues a JWT token with the user ID and signs the whole thing. And when the client uses this signed token, is it the stateless authentication for the backend?

kerem commented

2026-03-16 21:02:06 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Oct 14, 2024):

is it the stateless authentication for the backend?

yes, the token is signed and contains all the info the backend needs to authenticate and authorize a request coming in, the tokens are also short lived and contain a TTL info attached with as well and lives as long as the duration ACCESS_TOKEN_VALIDITY environment variable specifies, after which the frontend has to request for a token refresh with the given refresh token, the refresh token is a plain value stored in the DB and using it the client can get new access tokens.

Anything more to clarify ?

yes i can confirm it's for horizontal scaling, scaling loads and maybe version upgrades without downtime.

If so, can we rephrase this issue to be specifically addressing horizontal scaling concerns ? For our plans for the release this month, we are planning on resolving most of the blockers to horizontal scaling here. We are generally skeptical about recommending version upgrades without downtime, not because there are technical blockers, but mostly because we want to still preserve our ability to make breaking changes to the database, atleast for a couple more releases, but hopefully we can provide that in the future.

@AndrewBastin commented on GitHub (Oct 14, 2024): > is it the stateless authentication for the backend? yes, the token is signed and contains all the info the backend needs to authenticate and authorize a request coming in, the tokens are also short lived and contain a TTL info attached with as well and lives as long as the duration `ACCESS_TOKEN_VALIDITY` environment variable specifies, after which the frontend has to request for a token refresh with the given refresh token, the refresh token is a plain value stored in the DB and using it the client can get new access tokens. Anything more to clarify ? > yes i can confirm it's for horizontal scaling, scaling loads and maybe version upgrades without downtime. If so, can we rephrase this issue to be specifically addressing horizontal scaling concerns ? For our plans for the release this month, we are planning on resolving most of the blockers to horizontal scaling here. We are generally skeptical about recommending version upgrades without downtime, not because there are technical blockers, but mostly because we want to still preserve our ability to make breaking changes to the database, atleast for a couple more releases, but hopefully we can provide that in the future.

kerem referenced this issue

2026-03-17 01:02:21 +03:00

[PR #1599] [MERGED] refactor edit-team to use smart query #3422