Good article. I think recommending the use of encoding/gob for serializing structs is misguided though, json would be a much better and portable choice.
It depends. It definitely locks you into using Go. But it keeps you within the 4KB limit more easily. I wouldn’t use it on a serious project, but I’ve done it before on a throwaway where I just needed to store a user session cookie easily.
Also, while storing all state in the cookie, instead of in a database, is a nice trick, it’s hard to invalidate the cookies. Same problem with JWT in cookies. Unless you have a huge amount traffic, just put the sessions in postgres or redis and just store the session id in the cookie.
For secretbox, the nonce should go in a database, no? So, it wouldn’t really work as a client session cookie. I guess you could sign the nonce and store it in a second cookie?
Good article. I think recommending the use of encoding/gob for serializing structs is misguided though, json would be a much better and portable choice.
It depends. It definitely locks you into using Go. But it keeps you within the 4KB limit more easily. I wouldn’t use it on a serious project, but I’ve done it before on a throwaway where I just needed to store a user session cookie easily.
You can use gobs in other languages. Less supported, yes, but you write some tests around it and you can be robust enough for client side work.
Please use something like secretbox for encryption instead of building your own: https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox
Also, while storing all state in the cookie, instead of in a database, is a nice trick, it’s hard to invalidate the cookies. Same problem with JWT in cookies. Unless you have a huge amount traffic, just put the sessions in postgres or redis and just store the session id in the cookie.
For secretbox, the nonce should go in a database, no? So, it wouldn’t really work as a client session cookie. I guess you could sign the nonce and store it in a second cookie?