Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En omstart av en reverse proxy loggar ut alla användare endast när den samtidigt ändrar, förlorar eller omdirigerar det sessionstillstånd som applikationen använder.
En grundläggande proxy vidarebefordrar vanligtvis cookies i stället för att äga applikationens session, så en omstart av proxyn i sig bör inte ogiltigförklara alla inloggningar. Den verkliga utlösande faktorn kan vara en omstartad autentiseringsgateway, en återskapad hemlighet för cookiesignering, en sessionscache i minnet, ett byte av backend-replik eller ett Compose-beroende som startar om applikationen tillsammans med proxyn. Identifiera vilken komponent som utfärdade och validerar sessionen innan du ändrar cookieattribut eller tvingar användare att logga in igen.
Bekräfta vilka tjänster som startades om tillsammans med proxyn
Dokumentera container-ID:n, starttider, antal omstarter, hälsohändelser och loggar för reverse proxyn, autentiseringstjänsten, applikationen, cachen och databasen före och efter en kontrollerad omstart av proxyn.
Docker Compose kan starta om beroende tjänster när ett beroende uttryckligen har konfigurerats för att vidarebefordra omstarter. Den officiella vägledningen om startordning visar varför ett kommando som beskrivs som en omstart av proxyn även kan ersätta eller starta om en autentiserings- eller applikationscontainer.
Om endast proxyn får en ny starttid bör du fokusera på autentisering, routing och cookies som hanteras av proxyn. Om appen, cachen eller autentiseringsgatewayen också startas om bör du först granska deras sessionspersistens och hemligheter.
Identifiera vilket lager som utfärdade inloggningscookien
Innan du startar om bör du dokumentera cookiens namn, domän, sökväg, Secure, HttpOnly, SameSite, utgångstid och om den sätts av applikationen eller en autentiseringsgateway.
MDN förklarar att cookiens omfattning och attribut avgör var webbläsaren skickar den, men dessa attribut visar inte vilken backend som validerar dess värde.
Jämför svarshuvuden från inloggningsbegäran och den första begäran efter omstarten. En saknad cookie är ett problem med webbläsarens omfång; en oförändrad cookie som avvisas av servern tyder på förlorat tillstånd, ändrade nycklar eller en annan backend.
Kontrollera om en autentiseringsgateway återskapade sin sessionshemlighet
Granska autentiseringsgatewayens källa för hemligheten, filmontering, miljö, återskapande av containern och genererade konfiguration. Jämför källan till värdet före och efter omstarten utan att exponera själva hemligheten.
Authelia dokumenterar att dess sessionshemlighet krypterar lagrade sessionsdata, så om hemligheten ändras eller försvinner kan tjänsten inte läsa sessioner som skapades tidigare.
Lagra sessionshemligheter i en beständig hemlighetsfil eller i en hanterad hemlighetslagring i stället för att generera dem vid varje containerstart. Rotera dem medvetet och med ett dokumenterat utloggningsfönster.
Uteslut en sessionslagring i minnet
Identifiera om applikationen lagrar sessioner i processminnet, en lokal cache, Redis, en databas eller signerade cookies på klientsidan. Jämför sessionslagringens processtid med tidpunkten för utloggningen.
Django varnar för att en cachebaserad sessionsbackend kan förlora sessionsdata när cachen startas om eller rensar data, vilket loggar ut användare när sessionsdata försvinner.
Om proxystacken innehåller cachecontainern kan en omstart av stacken radera sessioner även om applikationscontainern fortfarande är igång. Använd en beständig cachekonfiguration eller en databassbaserad reservlösning när det är viktigt att inloggningen består.
Jämför applikationens signeringsnycklar mellan omstarter
Granska källan till applikationens sessionssignerings- eller krypteringsnyckel och fastställ om nyckeln är beständig, läses från den förväntade env-filen eller genereras vid uppstart.
Flask använder SECRET_KEY för att signera sessionscookies, så om nyckeln ersätts blir befintliga signerade cookies ogiltiga även när webbläsaren fortsätter att skicka dem.
Lös inte detta genom att dela en hemlighet mellan orelaterade applikationer. Ge varje app en stabil hemlighet, skydda den som säkerhetskritisk konfiguration och kontrollera att den överlever när avbilden återskapas.
Kontrollera sticky sessions och ändringar av backend-repliker
Lista backend-replikerna, deras sessionslagring och proxyns lastbalanseringspolicy. Testa om samma användare förblir inloggad när begäranden når en annan replik.
Traefiks konfiguration för sticky sessions dirigerar en klient tillbaka till en backend, men användare kan fortfarande förlora sessioner om replikerna inte delar tillstånd och en omstart ändrar den valda slutpunkten.
Sticky sessions kan dölja en felaktigt lokal sessionslagring. Använd helst ett delat och beständigt sessionstillstånd när flera apprepliker ska kunna överleva en ersättning av proxyn eller backend-systemet.
Återskapa problemet med ett testkonto och stabil konfiguration
Ta en ögonblicksbild av konfigurationen, logga in med ett engångskonto, dokumentera sessionsidentifierarna, starta om endast proxyn och testa samma begäran innan någon annan komponent startas om.
ZimaSpace-artikeln om inloggningsslingor endast utanför hemnätverket behandlar inloggningsfel som beror på sökvägen; den här artikeln fokuserar på samtidig ogiltigförklaring av redan giltiga sessioner efter en omstart.
Problemet är löst när omstarter av endast proxyn bevarar sessionerna, avsiktliga omstarter av autentisering eller app använder stabila hemligheter och beständigt tillstånd, och varje replik accepterar samma aktiva inloggning.
Vanliga frågor
Kan en reverse proxy själv lagra användarsessioner?
Det kan den om den innehåller en autentiseringsgateway, åtkomstmiddleware eller en mekanism för sticky sessions. En enkel vidarebefordrande proxy äger vanligtvis inte applikationens inloggningssession.
Loggas användare alltid ut när Redis startas om?
Endast när sessionerna finns enbart i Redis och dess data inte sparas eller återställs. Applikationer som använder databassbaserade sessioner eller signerade cookies fungerar annorlunda.
Bör jag öka cookiens livslängd för att stoppa utloggningar vid omstarter?
Nej. En cookie med längre livslängd fungerar fortfarande inte om signeringsnyckeln ändras eller om serverns sessionspost försvinner. Åtgärda persistens och stabila hemligheter först.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför slutar ett Compose-nätverksalias att fungera efter att stacken har återskapats under ett nytt projektnamn?
En Compose DNS-diagnos som omfattar projektnamn, nätverksomfattande alias, externa nätverk, inbäddad DNS, proxyanslutning, inaktuella slutpunkter och återskapande.
