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 😉

[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.

[datner]

I'm a bit confused, are we collectively pretending this is some novel far-flung idea or some niche use case because we enjoy hearing @xak2000 explain how basic session management works? Iron-Session is used inside, which itself exposes non-cookie interfaces through defining the seal/unseal methods, it quotes an OWASP document that basically doesn't even entertain the idea of the cookie being anything besides a session ID, and it quotes a ruby-on-rails document on session management that is actually just a very long list of vulnerabilities, limitations, and attack vectors that you're exposed to by using cookies alone and links to examples that none of which use the cookie storage method. I don't understand the hill of implementing only the easy part of sessions (writing the Set-Cookie header) and calling it a day..

I think that its quite straightforward what is suggested, not sure why an RFC is required. It's a hard thing to do, but it's a simple thing to understand. The current session api is just iron-session, which is just @hapi/iron, which express-session has taken inspiration from. All their apis are effectively identical, mutate the session object, everything else is behind the curtain. In other words, there is no api change required, only adding support for different storage media behind the scenes in the same existing manner useStorage exposes currently.

This is not to say I agree with the proposed api, but it is very clear what the proposed api is.
It is also fine to say 'nitro is not rails, we are not planning to do A B C', its the hesitant discord that is really uncomfortable to read