It entirely depends on which storage back-end you use.
The gorilla/sessions package has built-in cookie & filesystem based stores. There is no memory-based store, which is roughly what PHP's $_SESSION is.
My recommendation:
- Use the built-in cookie store, which uses signed cookies. It is well suited for most purposes and is the easiest to implement.
- If you have a need for server-side sessions (i.e. storing large values in the session), pick from the available implementations - Redis, BoltDB, mySQL, Postgres, etc.
I have first-hand experience with the Redis backed store (redistore), which has been great. The BoltDB (a file-based key store) and Postgres stores are also solid if you have a preference for those.
I want the users who didn't click on the "remember me" button on the login form to have their session erased after closing their browser, whereas everyone else will have a cookie associated with them. So would Gorilla sessions be able to handle both scenarios or should I use something else in this case?
Note that all implementations require a "cookie" - it's just whether the cookie is the self-contained store, or whether it just holds an identifier referring to a row/value in the back-end store.
You can set "session cookies" (i.e. last only as long as the tab/browser session) by setting session.Options.MaxAge = 0 as per this part of the gorilla/sessions docs.
e.g.
func MyHandler(w http.ResponseWriter, r *http.Request) {
session, err := store.Get(r, "session-name")
if err != nil {
http.Error(w, err.Error(), 500)
return
}
// Add your logic to check the r.FormValue for your remember_me checkbox.
// Temporary session
session.Options.MaxAge = 0
// Set some session values.
session.Values["user"] = someUser
// Save it before we write to the response/return from the handler.
session.Save(r, w)
}
Hope that helps.
