Dlaczego ponowne uruchomienie odwrotnego proxy unieważnia każdą sesję w jednej samodzielnie hostowanej aplikacji?
Restart serwera reverse proxy wylogowuje każdego użytkownika tylko wtedy, gdy jednocześnie zmienia, traci lub przekierowuje stan sesji używany przez daną aplikację.
Podstawowy serwer proxy zwykle przekazuje pliki cookie, zamiast zarządzać sesją aplikacji, dlatego sam restart proxy nie powinien unieważniać wszystkich logowań. Rzeczywistą przyczyną może być ponowne uruchomienie bramy uwierzytelniania, wygenerowanie nowego sekretu podpisującego pliki cookie, sesja przechowywana w pamięci, zmiana repliki backendu albo zależność Compose, która restartuje aplikację razem z proxy. Zanim zmienisz atrybuty plików cookie lub zmusisz użytkowników do ponownego logowania, ustal, który komponent wystawił sesję i który ją weryfikuje.
Potwierdź, które usługi zostały zrestartowane razem z proxy
Zapisz identyfikatory kontenerów, czasy uruchomienia, liczbę restartów, zdarzenia dotyczące kondycji oraz logi reverse proxy, usługi uwierzytelniania, aplikacji, pamięci podręcznej i bazy danych przed jednym kontrolowanym restartem proxy i po nim.
Docker Compose może restartować usługi zależne, gdy propagowanie restartu zależności jest jawnie skonfigurowane. Oficjalne wskazówki dotyczące kolejności uruchamiania wyjaśniają, dlaczego polecenie opisane jako restart proxy może również zastąpić lub zrestartować kontener uwierzytelniania albo aplikacji.
Jeśli tylko proxy otrzyma nowy czas uruchomienia, skup się na uwierzytelnianiu, routingu i plikach cookie zarządzanych przez proxy. Jeśli zrestartuje się również aplikacja, pamięć podręczna lub brama uwierzytelniania, najpierw sprawdź trwałość ich sesji i sekretów.
Ustal, która warstwa wystawiła plik cookie logowania
Przed restartem zapisz nazwę pliku cookie, domenę, ścieżkę, atrybuty Secure, HttpOnly i SameSite, czas wygaśnięcia oraz informację, czy ustawia go aplikacja, czy brama uwierzytelniania.
MDN wyjaśnia, że zakres i atrybuty pliku cookie określają, gdzie przeglądarka go wysyła, ale nie wskazują, który backend weryfikuje jego wartość.
Porównaj nagłówki odpowiedzi z żądania logowania i pierwszego żądania po restarcie. Brak pliku cookie wskazuje na problem z jego zakresem w przeglądarce; niezmieniony plik cookie odrzucony przez serwer wskazuje na utratę stanu, zmianę kluczy lub inny backend.
Sprawdź, czy brama uwierzytelniania ponownie wygenerowała sekret sesji
Sprawdź źródło sekretu bramy uwierzytelniania, podpięcie pliku, zmienne środowiskowe, ponowne utworzenie kontenera oraz wygenerowaną konfigurację. Porównaj źródło wartości przed restartem i po nim, nie ujawniając samego sekretu.
Authelia dokumentuje, że jej sekret sesji szyfruje dane sesji przechowywane w Redisie, dlatego jego zmiana lub utrata uniemożliwia usłudze odczytanie wcześniej utworzonych sesji.
Przechowuj sekrety sesji w trwałym pliku sekretów lub zarządzanym magazynie sekretów, zamiast generować je przy każdym uruchomieniu kontenera. Rotację przeprowadzaj celowo, z udokumentowanym oknem wylogowania.
Wyklucz sesję przechowywaną w pamięci
Ustal, czy aplikacja przechowuje sesje w pamięci procesu, lokalnej pamięci podręcznej, Redisie, bazie danych czy w podpisanych plikach cookie po stronie klienta. Porównaj czas działania procesu magazynu sesji z momentem wylogowania.
Django ostrzega, że backend sesji korzystający wyłącznie z pamięci podręcznej może utracić dane sesji po restarcie lub usunięciu wpisów z pamięci podręcznej, co wylogowuje użytkowników po zniknięciu danych sesji.
Jeśli stos proxy zawiera kontener pamięci podręcznej, jego restart może usunąć sesje, nawet gdy kontener aplikacji nadal działa. Użyj trwałej konfiguracji pamięci podręcznej lub awaryjnego magazynu opartego na bazie danych, gdy ciągłość logowania ma znaczenie.
Porównaj klucze podpisujące aplikacji po restartach
Sprawdź źródło klucza używanego przez aplikację do podpisywania lub szyfrowania sesji i ustal, czy klucz jest trwały, wczytywany z oczekiwanego pliku env lub generowany podczas uruchamiania.
Flask używa SECRET_KEY do podpisywania plików cookie sesji, dlatego zastąpienie tego klucza unieważnia istniejące podpisane pliki cookie, nawet jeśli przeglądarka nadal je wysyła.
Nie rozwiązuj tego problemu, używając jednego sekretu w niepowiązanych aplikacjach. Nadaj każdej aplikacji stabilny sekret, chroń go jako konfigurację krytyczną dla kopii zapasowych i sprawdź, czy przetrwa odtworzenie obrazu.
Sprawdź sesje trwałe i zmiany replik backendu
Wymień repliki backendu i używane przez nie magazyny sesji oraz sprawdź sposób równoważenia obciążenia przez proxy. Przetestuj, czy ten sam użytkownik pozostaje zalogowany, gdy żądania trafiają do innej repliki.
Konfiguracja sesji trwałych w Traefiku kieruje klienta z powrotem do jednego backendu, ale użytkownicy nadal mogą tracić sesje, jeśli repliki nie współdzielą stanu, a restart zmieni wybrany punkt końcowy.
Sesje trwałe mogą ukrywać nieprawidłowo skonfigurowany lokalny magazyn sesji. Jeśli wiele replik aplikacji ma przetrwać wymianę proxy lub backendu, preferuj współdzielony i trwały stan sesji.
Odtwórz problem za pomocą jednego konta testowego i stabilnej konfiguracji
Utwórz kopię konfiguracji, zaloguj się za pomocą jednego jednorazowego konta, zapisz identyfikatory sesji, zrestartuj wyłącznie proxy i przetestuj to samo żądanie przed zrestartowaniem dowolnego innego komponentu.
Artykuł ZimaSpace o pętlach logowania występujących tylko poza domową siecią omawia zależne od ścieżki problemy z logowaniem; ten artykuł koncentruje się na jednoczesnym unieważnieniu już aktywnych sesji po restarcie.
Problem jest rozwiązany, gdy restarty samego proxy zachowują sesje, celowe restarty uwierzytelniania lub aplikacji korzystają ze stabilnych sekretów i trwałego stanu, a każda replika akceptuje to samo aktywne logowanie.
Często zadawane pytania
Czy reverse proxy może samodzielnie przechowywać sesje użytkowników?
Tak, jeśli zawiera bramę uwierzytelniania, oprogramowanie pośredniczące kontroli dostępu lub mechanizm sesji trwałych. Proste proxy przekazujące żądania zwykle nie zarządza sesją logowania aplikacji.
Czy restart Redisa zawsze wylogowuje użytkowników?
Tylko wtedy, gdy sesje istnieją wyłącznie w Redisie, a jego dane nie są utrwalane ani odtwarzane. Aplikacje korzystające z sesji opartych na bazie danych lub podpisanych plikach cookie zachowują się inaczej.
Czy należy wydłużyć czas życia pliku cookie, aby zatrzymać wylogowania po restarcie?
Nie. Plik cookie o dłuższym czasie życia nadal przestanie działać, jeśli zmieni się klucz podpisujący lub zniknie serwerowy rekord sesji. Najpierw zapewnij trwałość danych i stabilność sekretów.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Przewodnik po pamięci masowej nagrywania telewizji na żywo: pojemność, przechowywanie i czyszczenie
Zmierz rzeczywiste nagrania, zarezerwuj zapas, połącz limity wieku i pojemności oraz potwierdź, że najstarszy kwalifikujący się program zostanie usunięty, zanim pamięć się zapełni.
Proces odzyskiwania metadanych multimediów domowych po przywróceniu bazy danych
Zabezpiecz przywrócony stan, zweryfikuj tożsamość multimediów i ścieżki, a następnie napraw brakujące grafiki lub dopasowania w pilotażowej bibliotece przed wprowadzeniem szeroko zakrojonych zmian metadanych.
Lista zgodności klientów Jellyfin z dźwiękiem, obrazem i napisami
Testuj reprezentatywne pliki, zmieniając jedną zmienną naraz, i rejestruj dla każdego klienta: bezpośrednie odtwarzanie, remultipleksowanie, konwersję dźwięku, transkodowanie wideo lub niepowodzenie.
