Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back NewCookieManager or equivalent functionality for v2 #221

Open
bradleypeabody opened this issue Oct 8, 2024 · 0 comments
Open

Comments

@bradleypeabody
Copy link

bradleypeabody commented Oct 8, 2024

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:

  • 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant