Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een herstart van een reverse proxy logt alle gebruikers alleen uit wanneer daarbij ook de sessiestatus die door de applicatie wordt gebruikt, wordt gewijzigd, verloren gaat of opnieuw wordt gerouteerd.
Een basisproxy stuurt cookies meestal door zonder de applicatiesessie zelf te beheren. Daarom zou alleen het herstarten van de proxy niet alle aanmeldingen ongeldig moeten maken. De werkelijke oorzaak kan een herstartte authenticatiegateway, een opnieuw gegenereerd cookie-ondertekeningsgeheim, een sessiecache in het geheugen, een gewijzigde backend-replica of een Compose-afhankelijkheid zijn die de app samen met de proxy herstart. Bepaal eerst welk onderdeel de sessie heeft uitgegeven en valideert voordat je cookiekenmerken wijzigt of gebruikers opnieuw laat inloggen.
Bevestig welke services samen met de proxy zijn herstart
Leg vóór en na één gecontroleerde herstart van de proxy de container-ID's, starttijden, herstartaantallen, gezondheidsgebeurtenissen en logs vast van de reverse proxy, authenticatieservice, applicatie, cache en database.
Docker Compose kan afhankelijke services herstarten wanneer een afhankelijkheid expliciet is geconfigureerd voor het doorgeven van herstarts. De officiële handleiding voor de opstartvolgorde laat zien waarom een opdracht die als een proxyherstart wordt omschreven, ook een authenticatie- of applicatiecontainer kan vervangen of herstarten.
Als alleen de proxy een nieuwe starttijd krijgt, richt je dan op authenticatie, routering en cookies die door de proxy worden beheerd. Als de app, cache of authenticatiegateway ook herstart, controleer dan eerst de persistentie van hun sessies en hun geheimen.
Identificeer welke laag de aanmeldcookie heeft uitgegeven
Leg vóór de herstart de cookienaam, het domein, het pad, Secure, HttpOnly, SameSite, de vervaldatum en vast of de applicatie of een authenticatiegateway de cookie instelt.
MDN legt uit dat het bereik en de kenmerken van cookies bepalen waar een browser ze naartoe stuurt, maar die kenmerken laten niet zien welke backend de waarde valideert.
Vergelijk de responseheaders van het inlogverzoek met die van het eerste verzoek na de herstart. Een ontbrekende cookie wijst op een probleem met het browserbereik; een ongewijzigde cookie die door de server wordt afgewezen, wijst op verloren status, gewijzigde sleutels of een andere backend.
Controleer of een authenticatiegateway het sessiegeheim opnieuw heeft gegenereerd
Controleer de bron van het geheim van de authenticatiegateway, de bestandskoppeling, de omgeving, het opnieuw aanmaken van de container en de gegenereerde configuratie. Vergelijk waar de waarde vandaan komt vóór en na de herstart zonder het geheim zelf bloot te geven.
Authelia documenteert dat het sessiegeheim opgeslagen sessiegegevens versleutelt. Als dat geheim wordt gewijzigd of verloren gaat, kan de service sessies die eerder zijn aangemaakt niet meer lezen.
Sla sessiegeheimen op in een persistent geheimenbestand of een beheerde geheimenopslag, in plaats van ze bij elke containerstart te genereren. Voer rotatie bewust uit met een gedocumenteerd uitlogvenster.
Sluit een sessieopslag in het geheugen uit
Bepaal of de applicatie sessies opslaat in procesgeheugen, een lokale cache, Redis, een database of ondertekende clientcookies. Vergelijk de uptime van het sessieopslagproces met het moment waarop gebruikers werden uitgelogd.
Django waarschuwt dat een cache-only-sessiebackend sessiegegevens kan verliezen wanneer de cache wordt herstart of opgeschoond. Hierdoor worden gebruikers uitgelogd zodra sessiegegevens verdwijnen.
Als de proxystack de cachecontainer bevat, kan het herstarten van die stack sessies wissen, ook wanneer de applicatiecontainer actief blijft. Gebruik een persistente cacheconfiguratie of een databasegestuurde fallback wanneer behoud van aanmeldingen belangrijk is.
Vergelijk de ondertekeningssleutels van de applicatie na herstarts
Controleer waar de sleutel voor sessieondertekening of versleuteling van de applicatie vandaan komt en bepaal of deze persistent is, uit het verwachte env-bestand wordt geladen of bij het opstarten wordt gegenereerd.
Flask gebruikt SECRET_KEY om sessiecookies te ondertekenen. Als die sleutel wordt vervangen, worden bestaande ondertekende cookies ongeldig, zelfs wanneer de browser ze nog steeds verstuurt.
Los dit niet op door één geheim te delen tussen niet-gerelateerde applicaties. Geef elke app een stabiel geheim, bescherm dit als back-upkritieke configuratie en controleer of het behouden blijft wanneer de image opnieuw wordt aangemaakt.
Controleer sticky sessions en wijzigingen in backend-replica's
Breng de backend-replica's, hun sessieopslag en het load-balancingbeleid van de proxy in kaart. Test of dezelfde gebruiker ingelogd blijft wanneer verzoeken een andere replica bereiken.
De sticky-sessionconfiguratie van Traefik stuurt een client terug naar één backend, maar gebruikers kunnen hun sessie nog steeds verliezen wanneer replica's geen status delen en een herstart het geselecteerde eindpunt wijzigt.
Sticky sessions kunnen een onjuist lokale sessieopslag verbergen. Geef de voorkeur aan gedeelde, duurzame sessiestatus wanneer meerdere app-replica's een proxy- of backendvervanging moeten kunnen overleven.
Reproduceer het probleem met één testaccount en een stabiele configuratie
Maak een momentopname van de configuratie, log in met één wegwerpaccount, leg de sessie-ID's vast, herstart alleen de proxy en test hetzelfde verzoek voordat je een ander onderdeel herstart.
Het ZimaSpace-artikel over inloglussen die alleen buitenshuis optreden behandelt padafhankelijke inlogproblemen; dit artikel richt zich op het gelijktijdig ongeldig maken van al geldige sessies na een herstart.
Het probleem is opgelost wanneer herstarts van alleen de proxy sessies behouden, bewuste herstarts van de authenticatie of app stabiele geheimen en persistente status gebruiken en elke replica dezelfde actieve aanmelding accepteert.
Veelgestelde vragen
Kan een reverse proxy zelf gebruikerssessies opslaan?
Dat kan wanneer de proxy een authenticatiegateway, toegangsmiddleware of sticky-sessionmechanisme bevat. Een eenvoudige doorstuurproxy beheert de aanmeldsessie van de applicatie meestal niet zelf.
Logt het herstarten van Redis gebruikers altijd uit?
Alleen wanneer sessies uitsluitend in Redis bestaan en de gegevens niet persistent worden opgeslagen of hersteld. Applicaties met databasegestuurde sessies of sessies in ondertekende cookies gedragen zich anders.
Moet ik de levensduur van cookies verlengen om uitloggen na een herstart te voorkomen?
Nee. Een cookie met een langere levensduur werkt nog steeds niet wanneer de ondertekeningssleutel verandert of de sessierecord aan de serverzijde verdwijnt. Los eerst de persistentie en stabiliteit van geheimen op.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een diagnose van geheugenlimieten met aandacht voor actieve cgroups, herstarten versus opnieuw aanmaken, Compose-velden, harde en zachte limieten, bovenliggende scopes, swap en runtime-heaps.
Waarom wordt een Compose-netwerkalias niet meer opgelost nadat de stack onder een nieuwe projectnaam opnieuw is aangemaakt?
Een Compose-DNS-diagnose over projectnamen, netwerkgebonden aliassen, externe netwerken, ingebouwde DNS, proxykoppeling, verouderde eindpunten en opnieuw aanmaken.
