Deno: Proposal: std/session

[getspooky]

Hello deno community ,
I think it would be an enrichment to std to have session included by default with several great drivers out of the box

• cookie - sessions are stored in secure, encrypted cookies.
• database - sessions are stored in a relational database.
• memcached / redis - sessions are stored in one of these fast, cache based stores.

What are your thoughts on that?

[ry]

We're open to adding it to std, but it would be great if there was already some existing code to look at. Are the modules you have in mind already in deno.land/x ?

[andreespirela]

@ry @getspooky Mandarine frameworks has a built-in session system. This one works as follows:
1- A request is received
2- A middleware verifies whether a “cookie for session” exists
3- An encrypted cookie is created (this cookie contains the session id) if it doesn’t already exist
4- A session object is created in the request context
5- If the session object contains new data, the session is stored (if new) or updated (if session object already had data and was already stored)

Few concepts:

Session Container: A Registry in memory which contains the active sessions & a couple methods for manipulation.

Resources about Mandarine sessions:

https://www.mandarinets.org/docs/mandarine/session-middleware (Explains the lifecycle, and relation to/with the request)

https://www.mandarinets.org/docs/master/mandarine/session-container (explains the session container)

I will gladly port this to STD @ry if it’s wanted, this can be made minimalist & adaptable to Deno std http. I believe there’s definately work to do here & I will gladly port these concepts to STD in a Deno & Global way outside any framework concept.

Note: This would be a sessions-in-memory concept as they are stored in a javascript registry. There can be work done on overriding these kind of behaviors like providing interfaces to the users (kind of like Go does with its interface for Database drivers) but we could alternatively provide an interface for session storage & container, besides the default implementation

[kitsonk]

I tend to feel these are all framework concerns, and really don't belong in std.