how to store session data in server side

[masyoudi]

hi everyone, currently when i want to store session in h3/nitro is implement useSession, but useSession is save the data inside cookie, i want to store session data in server side like express-session, how i can achieve it?

Any info will be appreciated.

[xak2000]

I agree. Session configuration should support different "drivers" like Nitro storage does.

Encrypt and store the whole session data in a cookie is one way to do it, but not always the best way (depending on the data size, security requirements, etc.). More often than not you need a traditional "Session id in the cookie, session data on the server" solution.

[cjpearson]

We had the same use case and have been using express-session like approach backed by unstorage. https://www.npmjs.com/package/@scayle/h3-session Maybe this is helpful

[kiki-kanri]

You can try https://www.npmjs.com/package/@kikiutils/nitro-session.

[gangsthub]

h3 already provides a useSession utility:

https://h3.unjs.io/examples/handle-session

However, there are plans to make it configurable at the nitro.config level (app level) to allow other kind of integrations as well. See Nitro's issue: #2221

h3's useSession's current limitation is that you need to specify the config object each time you invoke it. In order to see the complete list of options, go to: https://h3.unjs.io/examples/handle-session#options

If you want to use different drivers, or would like to explore alternatives, definitely check the mentioned libraries 😉

[xak2000]

@gangsthub I'm not sure you understand this feature request.

Yes, h3 already provides a useSession utilitiy and it is mentioned in the question. This feature request is not focused on session support or session configuration, but on support of storing the session data not in the cookie (as currently implemented), but on the server (as it is done in most other production-ready server frameworks).

Yes, there are 3rd party libraries to adapt this solution (all of them are one-person effort, so can't be really considered as a long-term production-ready solution), but I truly believe this should be implemented in the core (h3) as the current implementation is very niche. I don't think most people want to store session data in the cookie. Yes, sometimes it could be acceptable or even preferable, but often you need just good old server-side session storage with only session ID passed in the cookie.

If the only way to store session data was the classic server-side way, then you could probably say that h3 already supports the session and if you want to store the data in a cookie, please use a 3rd-party library. But not the other way around. In my opinion, storing session data in a cookie can't be the main and the only way.

[gangsthub]

Thank you for your explanation, @xak2000.

And yes, I misunderstood the original message, my apologies, @masyoudi!

I think we should create another feature request issue to ask for alternative drivers (other than cookies). Probably this is what @pi0 had in mind with the configurable session, as well, I don't know.

IMO, the session engine could also be implemented in a separate package under the Nitro's umbrella (https://github.com/orgs/nitrojsdev/).

@masyoudi do you think you could create the feature request?
👉🏽 https://github.com/unjs/nitro/issues/new?assignees=&labels=pending+triage&projects=&template=feature-request.yml

[cjpearson]

There is a related request for h3 here: unjs/h3#379 that you may find interesting. It includes an explanation behind the design of h3's built in useSession util.

[xak2000]

Thank you @cjpearson for the link. It was interesting to read.

Unfortunately, there is no explanation of why it is designed that way and why server-side session is even not considered to be implemented.

@pi0 said:

This is by the design of how useSession works. It encrypts all session into a barrier format into the cookies. This way we don't need any external storage while can preserve data.

But, it is obvious. Of course this is by design. :)

The problem is that this is not the best design for every use case. :) In real apps the session data could be too large to make storing it in the cookie practical. Also, security concerns could apply and while data is password-protected and encrypted, it still could be too risky (or just prohibited by law, enforced by company rules, etc.) to expose them to the client.

@pi0 suggested to just use session ID as a key to any server-side storage, so, basically, to invent the wheel for every project. It could be done, of course, but I still think that this use-case is too common to not be implemented in the core.

Properly implement storage for server-side session is tricky. You need to garbage-collect expierd sessions, prolongue non-expired on every request, solve race conditions, etc. Not every storage supports automatical expiring, so e.g. SQL driver to store the session should be very different from Redis driver..

In short, it is quite difficult task to properly implement server-side session management that is fast, reliable and secure. And session management is quite important part of any website. Even today, in the times of SPA and OIDC..

[pi0]

It would be nice if you can write an RFC about how you see persistent session support from user DX.

It can be another unjs project or in h3/Nitro core and we can expose hooks for storage, renewal, and disposal, I don't think it would be that complex. But RFC can make to think better.