Sessions: securecookie : la valeur n'est pas valide

Comment l'avez-vous résolu ? :)

Je vois cela aussi et j'aimerais savoir comment l'effacer/le résoudre.

Le comportement d'erreur est-il cohérent ? Ou cela n'affecte-t-il que certaines demandes ?

Le jeu. 18 juin 2015 à 14h04 Dominic Hamon [email protected]
a écrit:

Je vois cela aussi et j'aimerais savoir comment l'effacer/le résoudre.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/gorilla/sessions/issues/16#issuecomment-113047123 .

J'ai pu atténuer cela en renvoyant une page valide lorsque j'ai rencontré l'erreur (au lieu de 500), puis en supprimant manuellement le cookie du navigateur. Je pense que cela est dû au fait que je mets à jour les clés d'authentification/chiffrement mais que j'ai un cookie côté navigateur à partir d'une session existante.

Je ne sais pas quelle est la bonne façon d'atténuer cela à long terme, donc tout conseil est le bienvenu.

Si vous voulez éviter cela, vous avez besoin d'un moyen pour votre application de migrer les clés.

Je suis également tombé sur ce problème. J'ai fini par ignorer l'erreur, car la documentation gorilla/sessions dit qu'une nouvelle session est toujours renvoyée. Vous pouvez toujours appeler session.Save() , et ensuite le navigateur demandeur aura un nouveau cookie de session valide.

J'étais confronté au même problème et c'était un peu difficile à repérer au début, le problème est que j'avais
var store = sessions.NewCookieStore(securecookie.GenerateRandomKey(10))
donc chaque fois que je redémarre le serveur, une nouvelle clé pour le magasin est générée, et si vous avez précédemment enregistré le cookie dans le navigateur Web, cela provoquerait une erreur lors de la tentative de décodage du cookie car il utilise la nouvelle clé et pas la clé lorsque le cookie a été créé au départ.
Cela pourrait être un problème difficile à repérer, voire pire lors du déploiement dans kubernetes, car parfois un nœud (une machine) doit redémarrer et ce nœud générera sa propre clé et cela pourrait provoquer un conflit avec les autres nœuds. Je recommanderais de ne pas générer de clé aléatoire, mais d'insérer manuellement une clé afin de ne pas rencontrer ce problème, comme :
var store = sessions.NewCookieStore([]byte("asdaskdhasdhgsajdgasdsadksakdhasidoajsdousahdopj"))

Vous ne devez pas intégrer de clés/informations d'identification dans votre code source. Au lieu de cela, vous devez les transmettre via l'environnement - par exemple os.Getenv("APPNAME_SESSION_KEY") . Cet environnement peut être amorcé par votre système de déploiement - dans le cas de k8s, en utilisant la fonctionnalité Secrets : https://kubernetes.io/docs/concepts/configuration/secret/#using -secrets-as-environment-variables

Je suis également affecté par un long jeton keycloak.