Reel sessions: concurrent hash of hashes.

[digitalextremist]

@tarcieri I'm thinking of creating a reel-extras repository for features like this which interact with Reel directly ( i.e. affecting headers on responses ). This would be reel-extras/session and would be one style only, using a concurrent hash of hashes. So in a sense it also prompts something like celluloid-extras with a concurrent hash in that. Mostly I wonder what the term should be if not -extras.

There ought to be an includeable module and methods to drop a cookie on a client and track a session, and keep a hash of data relative to that cookie:

1. Check the headers for Cookie and pull the appropriate id key from it.
2. If the key is not present in the cookie, or no cookie is present:
   1. Set a key, store the key, and attach a concurrent hash to it.
   2. Return the key with Set-Cookie in the response headers.
3. Re-check the headers on the next request for Cookie as usual, if it's not set, rerun step 2.
4. Provide access to the session hash by using the id/key to pull from the concurrent hash.

[digitalextremist]

It is important that session mapping does not dead-lock or slow down the server itself from processing requests and responses.

[mistergibson]

Wonderful idea.

[Asmod4n]

Cookies are a waste of bandwidth.

[digitalextremist]

@Asmod4n are you joking, or do you have another approach to identifying unique participants and keep persistence over sometimes several days?

[Asmod4n]

JavaScript local/session Storage. Since you have to use crypto anyway you can just store a identifier on the client and have it send as a url parameter when its needed and not every time a request is made.

[digitalextremist]

Hmm. This is a very good approach, but it doesn't seem reliable enough. For example, a lot of my usages don't render HTML at all, but need an identifier present. Like an image or css file being loaded dynamically.

[Asmod4n]

Like, only send this image/css etc when someone is authenticated/authorized?

[digitalextremist]

Like determining server-state by client-provided hostname, tagging that for future sessions ( rather than continually comparing a hostname to a Hash of possible related data ) ... instead I just pull the ID from the cookie and use it. So for multitenancy. For example, skins.* is mapped to any domain, and it needs to know what the skin of the domain is to know where the file is. Or host/skin is the same situation.

[Asmod4n]

Hm, this here might be a good read on something like that: https://neosmart.net/blog/2015/using-hmac-signatures-to-avoid-database-writes/

[tarcieri]

Yes, there's no reason to have any sort of central session store. Cookies are stateless from the server's perspective and allow you to scale horizontally.

Storing a short-lived bearer credential in the DOM is a nice technique if you're making a single-page HTML/JS application and don't mind making users authenticate every time they load the page (as the credential is lost as soon as they navigate away). However, requiring users to authenticate each time they load a page is typically a nonstarter from a user experience perspective.

This is where people start to loop in things like localStorage to persist in-DOM credentials and make them into a sort of cookie replacement. However, localStorage has a wide range of security issues and prevents you from leveraging features of cookies like the HttpOnly setting that prevents cookies from ever being exposed to the DOM, so long-term credentials can potentially be obtained via XSS.

Cookies have their own set of problems of course (e.g. CSRF, they don't honor the same origin policy, they don't inform the server how they were set, they're potentially vulnerable to session fixation) but are probably the best tool for the job if you want sessions that live across page loads.

I'd recommend looking at JOSE JWE and JWT for a cookie format. There's a few gems for it, such as this one:

https://github.com/nov/json-jwt