securecookie: the value is not valid

[danvonk]

Hi, I get this error when trying to call store.Get() on a request from websocket.Conn.Request()

session, err := store.Get(conn.Request(), "my_session")

The error originates from the verifyMac function of gorilla/securecookie.

[FraBle]

How did you solve it? :)

[dmah42]

I'm seeing this too and would love to know how to clear it/solve it.

[elithrar]

Is the error behavior consistent? Or does it only affect some requests?

On Thu, 18 Jun 2015 at 2:04 pm Dominic Hamon notifications@github.com wrote:

I'm seeing this too and would love to know how to clear it/solve it.

— Reply to this email directly or view it on GitHub https://github.com/gorilla/sessions/issues/16#issuecomment-113047123.

[dmah42]

I was able to mitigate this by returning a valid page when I hit the error (instead of a 500) and then deleting the cookie manually from the browser. I think it's caused by me updating the auth/encrypt keys but having a cookie on the browser side from an existing session.

i don't know what the right way to mitigate this is in the long-term, so any advice is welcome.

[kisielk]

If you you want to avoid this you need a way for your application to migrate keys.

[nucleartide]

I ran into this issue too. I ended up just ignoring the error, since the gorilla/sessions docs say that a new session is still returned. You can still call session.Save(), and afterward the requesting browser will have a new, valid session cookie.

[johnbalvin]

I was facing the same issue and it was a lit bit difficult to spot at first, the problem is that I had var store = sessions.NewCookieStore(securecookie.GenerateRandomKey(10)) so each time I restart the server, a new key for the store is been generated, and if you previously have saved the cookie into web browser, then it would cause an error when trying to decode the cookie because it is using the new key and not the key when the cookie was created at first. This could be an issue difficult to spot even worst when deploying into kubernetes, because sometimes a node(machine) needs to restart and that node will generate it´s own key and that could cause a conflict with the others nodes. I would recommend not to generate a random key, instead, insert manually a key so you won´t face that issue, like: var store = sessions.NewCookieStore([]byte("asdaskdhasdhgsajdgasdsadksakdhasidoajsdousahdopj"))

[elithrar]

You shouldn't embed keys/credentials into your source code. Instead, you should pass them in via the environment - e.g. os.Getenv("APPNAME_SESSION_KEY"). That environment may be bootstrapped by your deployment system - in the k8s case, using the Secrets functionality: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables

[RubenGarcia]

I am also affected due a long keycloak token.

[SharkFourSix]

You shouldn't embed keys/credentials into your source code. Instead, you should pass them in via the environment - e.g. os.Getenv("APPNAME_SESSION_KEY"). That environment may be bootstrapped by your deployment system - in the k8s case, using the Secrets functionality: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables

You should also be cautious using ENV variables because on linux you do not need sudo privileges to peek into other process's ENV variables. :wink:. Meaning anyone that can list processes on an instance can easily grab those secrets without needing to have access to the .ENV file.