0

It seems to me that as long as you only want to store simple values like a timestamp for last visit and maybe a userid in the session, there's really no point at all in using Redis as a session persistence with Gorilla sessions since they seem to be storing it in cookies on the client side anyways.

Am I correct or not in this assumption?

I understand that there's a size limit and also that if I were to store sessions on file (the other available storage option with gorilla sessions), it'd be impossible to scale beyond that machine but again, is this whole "session store" a non issue with gorilla sessions cookie store?

Btw, I've seen this question here and NO it doesn't address this issue so it's not a duplicate. What is the advantage of using Gorilla sessions custom backend?

Community
  • 1
  • 1
Adergaard
  • 760
  • 10
  • 24

1 Answers1

3

Using Redis (or any other server-side store) can help avoid a whole class of problems, namely:

  1. Large cookie sizes adding per-request overhead - even an additional 4K per request can be a lot on mobile connections.
  2. Severely reducing the risk of cookie data being manipulated as it is stored server-side.
  3. Ability to store more than 4K in the session (i.e. form data from a multi-step form)
  4. ... and in Redis' case, the ability to easily expire the server-side sessions (something that's more error prone with mySQL or a filesystem store.

A cookie is still required as it must store an identifier so the user can be associated with their server-side session. This isn't particular to gorilla/sessions whatsoever and is how nearly all other server-side session implementations behave.

If you think your use case is simple then sure, stick with cookie-based sessions. gorilla/sessions makes it easy enough to change out the backing store at a later date.

elithrar
  • 23,364
  • 10
  • 85
  • 104