Sessions: securecookie: der Wert ist ungültig

Wie hast du es gelöst? :)

Ich sehe das auch und würde gerne wissen, wie man es löscht / löst.

Ist das Fehlerverhalten konsistent? Oder betrifft es nur einige Anfragen?

Am Do, 18. Juni 2015 um 14:04 Uhr Dominic Hamon [email protected]
schrieb:

Ich sehe das auch und würde gerne wissen, wie man es löscht / löst.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/gorilla/sessions/issues/16#issuecomment -113047123.

Ich konnte dies abschwächen, indem ich beim Auftreten des Fehlers eine gültige Seite zurückgab (anstelle einer 500) und das Cookie dann manuell aus dem Browser löschte. Ich denke, es wird dadurch verursacht, dass ich die Authentifizierungs- / Verschlüsselungsschlüssel aktualisiere, aber ein Cookie auf der Browserseite von einer bestehenden Sitzung habe.

Ich weiß nicht, wie dies langfristig der richtige Weg ist, daher ist jeder Rat willkommen.

Wenn Sie dies vermeiden möchten, benötigen Sie eine Möglichkeit für Ihre Anwendung, Schlüssel zu migrieren.

Ich bin auch auf dieses Problem gestoßen. Am Ende habe ich den Fehler einfach ignoriert, da die Gorilla/Sessions-Dokumente sagen, dass immer noch eine neue Sitzung zurückgegeben wird. Sie können immer noch session.Save() aufrufen und der anfragende Browser hat danach ein neues, gültiges Sitzungs-Cookie.

Ich stand vor dem gleichen Problem und es war anfangs etwas schwer zu erkennen, das Problem ist, dass ich es hatte
var store = sessions.NewCookieStore(securecookie.GenerateRandomKey(10))
Jedes Mal, wenn ich den Server neu starte, wird ein neuer Schlüssel für den Speicher generiert, und wenn Sie das Cookie zuvor im Webbrowser gespeichert haben, würde es beim Versuch, das Cookie zu entschlüsseln, zu einem Fehler führen, da es den neuen Schlüssel verwendet und nicht der Schlüssel, als das Cookie zuerst erstellt wurde.
Dies könnte ein Problem sein, das bei der Bereitstellung in Kubernetes schwer zu erkennen ist, da manchmal ein Knoten (eine Maschine) neu gestartet werden muss und dieser Knoten seinen eigenen Schlüssel generiert, was zu einem Konflikt mit den anderen Knoten führen kann. Ich würde empfehlen, keinen zufälligen Schlüssel zu generieren, sondern manuell einen Schlüssel einzufügen, damit Sie dieses Problem nicht haben, wie zum Beispiel:
var store = sessions.NewCookieStore([]byte("asdaskdhasdhgsajdgasdsadksakdhasidoajsdousahdopj"))

Sie sollten keine Schlüssel/Anmeldeinformationen in Ihren Quellcode einbetten. Stattdessen sollten Sie sie über die Umgebung übergeben - zB os.Getenv("APPNAME_SESSION_KEY") . Diese Umgebung kann von Ihrem Bereitstellungssystem gebootet werden – im Fall von k8s mithilfe der Secrets-Funktion: https://kubernetes.io/docs/concepts/configuration/secret/#using -secrets-as-environment-variables

Ich bin auch von einem langen Schlüsselumhang-Token betroffen.