4 ms·

Interesting. Not sure why you'd keep them intact. What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hap

by tbiehn 11y ago

Interesting. Not sure why you'd keep them intact. What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hapi.js, found out that many people encrypt these and stuff them into cookies, ASP style - with all the same patterns of fail. Also - the developers claim this is a feature (after all, you don't have to worry about load balancing or distributing your state information on the backend. sigh )

elithrar 11y ago
gorilla/sessions (for which I became a maintainer last year) has Redis/BoltDB/Postgres/etc. backends: the cookie stores an opaque ID, and all the data is in the server side store (allowing you forced expiration, etc). Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.
- tbiehn 11y ago
  Very cool, I'll have to take a look at the gorilla/sessions work. As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that. If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.
- misiti3780 11y ago
  thank you for your hard work!
- e12e 11y ago
  I wonder how long it'll take before we get usable TLS-based sessions again. AFIK the only way to do that now, is via client certificates, and the UI for that (on the browser end) is still so bad it's practically unusable. I think it's perfectly valid (in an imperfect world) to use a (secure) cookie as a session token a la kerberos over http(s) -- and with authenticated encryption wrapped around the cookie I don't see much problem "storing" some session state in there (opaque to the user agent/user). Still somewhat unclear what that actually buys you in terms of scalability/simplicity -- all communication should be over TLS anyway, which means there will be a session context between the user agent and the TLS terminating server/load balancer (or if you have none, between the ua and the web server). I suppose it allows you to separate the user session from the TLS session -- which might be "fine" from a system level view, but I don't think it's really a security "win". Anyway, I'm happy people like you take the time to maintain stuff like gorilla/sessions -- it's part of what makes modern languages/frameworks so easy to use to get stuff done (and get them done in a sane way...).

by tbiehn 11y ago

elithrar 11y ago

gorilla/sessions (for which I became a maintainer last year) has Redis/BoltDB/Postgres/etc. backends: the cookie stores an opaque ID, and all the data is in the server side store (allowing you forced expiration, etc). Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.

tbiehn 11y ago
Very cool, I'll have to take a look at the gorilla/sessions work. As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that. If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.
misiti3780 11y ago
thank you for your hard work!
e12e 11y ago
I wonder how long it'll take before we get usable TLS-based sessions again. AFIK the only way to do that now, is via client certificates, and the UI for that (on the browser end) is still so bad it's practically unusable. I think it's perfectly valid (in an imperfect world) to use a (secure) cookie as a session token a la kerberos over http(s) -- and with authenticated encryption wrapped around the cookie I don't see much problem "storing" some session state in there (opaque to the user agent/user). Still somewhat unclear what that actually buys you in terms of scalability/simplicity -- all communication should be over TLS anyway, which means there will be a session context between the user agent and the TLS terminating server/load balancer (or if you have none, between the ua and the web server). I suppose it allows you to separate the user session from the TLS session -- which might be "fine" from a system level view, but I don't think it's really a security "win". Anyway, I'm happy people like you take the time to maintain stuff like gorilla/sessions -- it's part of what makes modern languages/frameworks so easy to use to get stuff done (and get them done in a sane way...).