Warum macht ein Neustart des Reverse-Proxys jede Sitzung für eine selbst gehostete App ungültig?

Ein Neustart des Reverse-Proxys meldet nur dann alle Benutzer ab, wenn dabei auch der von der Anwendung verwendete Sitzungsstatus geändert, verloren oder umgeleitet wird.

Ein einfacher Proxy leitet normalerweise Cookies weiter, anstatt die Anwendungssitzung selbst zu verwalten. Daher sollte ein alleiniger Proxy-Neustart nicht sämtliche Anmeldungen ungültig machen. Der tatsächliche Auslöser kann ein neu gestartetes Authentifizierungs-Gateway, ein neu erzeugtes Cookie-Signaturschlüssel, ein Sitzungs-Cache im Arbeitsspeicher, ein Wechsel des Backend-Replikats oder eine Compose-Abhängigkeit sein, die die Anwendung zusammen mit dem Proxy neu startet. Ermitteln Sie, welche Komponente die Sitzung ausgestellt und validiert hat, bevor Sie Cookie-Attribute ändern oder Benutzer erneut zur Anmeldung zwingen.

Bestätigen Sie, welche Dienste zusammen mit dem Proxy neu gestartet wurden

Erfassen Sie vor und nach einem kontrollierten Proxy-Neustart die Container-IDs, Startzeiten, Neustartzähler, Health-Ereignisse und Protokolle für den Reverse-Proxy, den Authentifizierungsdienst, die Anwendung, den Cache und die Datenbank.

Docker Compose kann abhängige Dienste neu starten, wenn für eine Abhängigkeit ausdrücklich eine Neustartweitergabe konfiguriert ist. Die offizielle Anleitung zur Startreihenfolge zeigt, warum ein als Proxy-Neustart beschriebener Befehl auch einen Authentifizierungs- oder Anwendungscontainer ersetzen oder neu starten kann.

Wenn nur der Proxy eine neue Startzeit erhält, konzentrieren Sie sich auf die vom Proxy verwaltete Authentifizierung, das Routing und die Cookies. Wird auch der App-, Cache- oder Authentifizierungsdienst neu gestartet, prüfen Sie zuerst die Persistenz der Sitzungen und die geheimen Schlüssel.

Ermitteln Sie, welche Schicht das Anmelde-Cookie ausgestellt hat

Erfassen Sie vor dem Neustart den Cookie-Namen, die Domain, den Pfad, Secure, HttpOnly, SameSite, das Ablaufdatum sowie die Information, ob die Anwendung oder ein Authentifizierungs-Gateway das Cookie setzt.

MDN erklärt, dass Gültigkeitsbereich und Attribute eines Cookies bestimmen, wohin ein Browser es sendet. Diese Attribute zeigen jedoch nicht, welches Backend seinen Wert validiert.

Vergleichen Sie die Antwort-Header der Anmeldeanforderung mit denen der ersten Anforderung nach dem Neustart. Ein fehlendes Cookie weist auf ein Browser- oder Gültigkeitsbereichsproblem hin; ein unverändertes Cookie, das vom Server abgelehnt wird, deutet auf verlorenen Status, geänderte Schlüssel oder ein anderes Backend hin.

Prüfen Sie, ob ein Authentifizierungs-Gateway sein Sitzungsschlüssel neu erzeugt hat

Prüfen Sie die Quelle des Sitzungsschlüssels des Authentifizierungs-Gateways, den Dateieinhängepunkt, die Umgebungsvariablen, die Neuerstellung des Containers und die erzeugte Konfiguration. Vergleichen Sie die Quelle des Werts vor und nach dem Neustart, ohne das Geheimnis selbst offenzulegen.

Authelia dokumentiert, dass sein Sitzungsschlüssel gespeicherte Sitzungsdaten verschlüsselt. Wird dieser Schlüssel geändert oder geht er verloren, kann der Dienst zuvor erstellte Sitzungen nicht mehr lesen.

Speichern Sie Sitzungsschlüssel in einer persistenten Geheimnisdatei oder einem verwalteten Secret Store, anstatt sie bei jedem Containerstart neu zu erzeugen. Führen Sie Schlüsselrotationen bewusst und mit einem dokumentierten Abmeldezeitraum durch.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Schließen Sie einen Sitzungs-Store im Arbeitsspeicher aus

Ermitteln Sie, ob die Anwendung Sitzungen im Prozessspeicher, in einem lokalen Cache, in Redis, einer Datenbank oder in signierten Client-Cookies speichert. Vergleichen Sie die Laufzeit des Sitzungs-Store-Prozesses mit dem Zeitpunkt der Abmeldung.

Django warnt davor, dass ein Cache-basierter Sitzungs-Backend Sitzungsdaten verlieren kann, wenn der Cache neu gestartet oder geleert wird. Dadurch werden Benutzer abgemeldet, sobald Sitzungsdaten verschwinden.

Wenn der Proxy-Stack den Cache-Container umfasst, kann ein Neustart dieses Stacks Sitzungen löschen, obwohl der Anwendungcontainer weiterhin läuft. Verwenden Sie eine persistente Cache-Konfiguration oder einen datenbankgestützten Fallback, wenn die Anmeldekontinuität wichtig ist.

Vergleichen Sie die Signaturschlüssel der Anwendung nach Neustarts

Prüfen Sie die Quelle des Sitzungs-Signaturschlüssels oder Verschlüsselungsschlüssels der Anwendung und stellen Sie fest, ob der Schlüssel persistent gespeichert, aus der erwarteten Env-Datei geladen oder beim Start erzeugt wird.

Flask verwendet SECRET_KEY zum Signieren von Sitzungscookies. Wird dieser Schlüssel ersetzt, werden vorhandene signierte Cookies ungültig, auch wenn der Browser sie weiterhin sendet.

Beheben Sie dies nicht, indem Sie ein gemeinsames Geheimnis für voneinander unabhängige Anwendungen verwenden. Geben Sie jeder Anwendung ein stabiles Geheimnis, schützen Sie es als kritische Sicherungskonfiguration und überprüfen Sie, dass es eine Neuerstellung des Images übersteht.

Prüfen Sie Sticky Sessions und Änderungen an Backend-Replikaten

Listen Sie die Backend-Replikate, ihre Sitzungs-Stores und die Load-Balancing-Richtlinie des Proxys auf. Testen Sie, ob derselbe Benutzer angemeldet bleibt, wenn Anforderungen ein anderes Replikat erreichen.

Die Sticky-Session-Konfiguration von Traefik leitet einen Client wieder an dasselbe Backend. Benutzer können Sitzungen jedoch trotzdem verlieren, wenn Replikate ihren Status nicht gemeinsam nutzen und ein Neustart den ausgewählten Endpunkt ändert.

Sticky Sessions können einen falsch konfigurierten lokalen Sitzungs-Store verbergen. Bevorzugen Sie einen gemeinsamen, dauerhaften Sitzungsstatus, wenn mehrere App-Replikate Proxy- oder Backend-Ersetzungen überstehen sollen.

Reproduzieren Sie den Fehler mit einem Testkonto und stabiler Konfiguration

Erstellen Sie eine Momentaufnahme der Konfiguration, melden Sie sich mit einem entbehrlichen Konto an, erfassen Sie die Sitzungskennungen, starten Sie nur den Proxy neu und testen Sie dieselbe Anforderung, bevor Sie eine andere Komponente neu starten.

Der ZimaSpace-Artikel über Anmeldeschleifen außerhalb des Heimnetzwerks behandelt pfadabhängige Anmeldefehler. Dieser Artikel konzentriert sich auf die gleichzeitige Ungültigmachung bereits gültiger Sitzungen nach einem Neustart.

Das Problem ist behoben, wenn reine Proxy-Neustarts Sitzungen erhalten, bewusste Neustarts von Authentifizierungsdienst oder Anwendung stabile Schlüssel und persistenten Status verwenden und jedes Replikat dieselbe aktive Anmeldung akzeptiert.

Häufig gestellte Fragen

Kann ein Reverse-Proxy selbst Benutzersitzungen speichern?

Das ist möglich, wenn er ein Authentifizierungs-Gateway, eine Zugriffs-Middleware oder einen Sticky-Session-Mechanismus umfasst. Ein einfacher Weiterleitungs-Proxy verwaltet die Anmeldesitzung der Anwendung normalerweise nicht selbst.

Melden Neustarts von Redis Benutzer immer ab?

Nur wenn Sitzungen ausschließlich in Redis vorhanden sind und dessen Daten nicht persistent gespeichert oder wiederhergestellt werden. Anwendungen mit datenbankgestützten oder signierten Cookie-Sitzungen verhalten sich anders.

Sollte ich die Cookie-Laufzeit verlängern, um Abmeldungen nach Neustarts zu verhindern?

Nein. Ein länger gültiges Cookie funktioniert weiterhin nicht, wenn sich sein Signaturschlüssel ändert oder der serverseitige Sitzungseintrag verschwindet. Beheben Sie zuerst die Persistenz und die Stabilität der geheimen Schlüssel.