sessions

Looks totally fine at first glance. I'm happily using https://github.com/gorilla/sessions to handle cookies right now — OP, is there any reason I should want to switch to your library instead?

I find that this is a totally fine trade off to make until it isn't, and by then you're completely confined by your choice of framework. Better to use libraries built to compose around interfaces taken from the standard library so you lose none of the control. I'll also emphasize that doing it this way does make discovering the initial pieces harder than if they're all in one framework together, but I find the slight increase in research yields orders of magnitude improved results once your code starts to age past the two year mark and you reap all the reliability and composibility of the standard library. Also, here's a list of out-of-the-box library implementations for all the features you mentioned: Sessions: https://github.com/gorilla/sessions CSRF: https://github.com/gorilla/csrf User auth: https://github.com/qor/auth

On this topic, and as a co-maintainer (but not original author) of gorilla/securecookie, which is mentioned in this article: - Setting Secure and HttpOnly attributes are exactly what I do by default in gorilla/csrf - you have to explicitly override these[1] - CSRF prevention without these is a losing battle. I'm positive many devs miss the docs though, wonder why the library isn't working on their local machine (without HTTPS), and move on to a library that doesn't have these safe defaults. This is a hard thing to fix: docs only go so far. - securecookie just returns the authenticated, and optionally encrypted, cookie value. It's pretty minimal. I'm already looking at a v2 with some breaking API changes[2], including using an AEAD instead of the original authors' AES+CBC + HMAC construct. This could also be an opportunity to provide a con

And https://github.com/gorilla/sessions for sessions.

"securecookies" is a term used, at least in the context of github.com/gorilla/sessions, to refer to a session storage based on encrypting all of the session data and sending it as a cookie. That means all of your session data, including if the user is authenticated and even which user it is, is sent to the browser and back to the server on the next (and subsequent) request(s). This is an interesting concept, but IMHO, rather flawed. About the only valid use is for small micro-apps that don't have any server side persistent storage. A db based session, which really wouldn't be that hard to set up with github.com/gorilla/sessions, would just send a randomly generated session id to the client in a cookie, save the data in the db, then read that data back out of the db on the next request.