You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I realize the OWASP cheat sheet on this subject advises using a database for the session storage on the server side. However, that document doesn't really speak to the actual tradeoffs related to storing session info in encrypted cookies. (It basically just advises to use a database and doesn't address the possibility of using an encrypted cookie.)
I also realize that a common pattern for applications is to basically stuff a bunch of stuff in the session, and a lot of apps have a mess of all kinds of little things they tuck into the session from one request to another to make various things work. It's convenient, but in my experience it's a pattern that can really quickly get one into trouble and it can introduce all kinds of hard to test and reproduce edge cases of sessions state being set to various values in weird and wonderful ways.
In my experience it tends to be far better to:
Only record who is logged in and some minimal amount of information about the lifetime of the session itself. An example of this information could be: real user id (who logged in), effective user id (allowing impersonation of another user), session expiration time.
Encrypt this and put it in a cookie. Now you can decrypt it anywhere you have the key, and only use a little CPU to do it, without having to reach back to database. The user ID info can be cached much more easily than individual sessions.
Put all of the other state like flash messages, etc into the UI or the URL. In the UI it won't affect backend logic. And in the URL it can be easily tested and much more deterministic. It also has performance benefits.
This is the sort of setup I was hoping to accomplish with scs and I was hoping that NewCookieManager could help me do this, but it seems like this was dropped in v2.
Is there any info on this or another way to support this approach?
The text was updated successfully, but these errors were encountered:
After reading through #44 and noticing that v1 has https://pkg.go.dev/github.com/alexedwards/scs#NewCookieManager, I'm wondering if this functionality was dropped from v2 for a specific reason? (Or maybe I'm just missing where it is?)
I realize the OWASP cheat sheet on this subject advises using a database for the session storage on the server side. However, that document doesn't really speak to the actual tradeoffs related to storing session info in encrypted cookies. (It basically just advises to use a database and doesn't address the possibility of using an encrypted cookie.)
I also realize that a common pattern for applications is to basically stuff a bunch of stuff in the session, and a lot of apps have a mess of all kinds of little things they tuck into the session from one request to another to make various things work. It's convenient, but in my experience it's a pattern that can really quickly get one into trouble and it can introduce all kinds of hard to test and reproduce edge cases of sessions state being set to various values in weird and wonderful ways.
In my experience it tends to be far better to:
This is the sort of setup I was hoping to accomplish with scs and I was hoping that NewCookieManager could help me do this, but it seems like this was dropped in v2.
Is there any info on this or another way to support this approach?
The text was updated successfully, but these errors were encountered: