Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?

Il riavvio di un reverse proxy disconnette tutti gli utenti solo quando modifica, perde o reindirizza anche lo stato della sessione utilizzato dall’applicazione.

Un proxy di base di solito inoltra i cookie senza gestire direttamente la sessione dell’applicazione, quindi il solo riavvio del proxy non dovrebbe invalidare tutti gli accessi. Il vero fattore scatenante potrebbe essere il riavvio di un gateway di autenticazione, la rigenerazione di un segreto per la firma dei cookie, una cache delle sessioni in memoria, la modifica di una replica backend o una dipendenza Compose che riavvia l’app insieme al proxy. Identifica quale componente ha emesso e convalida la sessione prima di modificare gli attributi dei cookie o obbligare nuovamente gli utenti ad accedere.

Conferma quali servizi sono stati riavviati insieme al proxy

Registra gli ID dei container, gli orari di avvio, il numero di riavvii, gli eventi di integrità e i log del reverse proxy, del servizio di autenticazione, dell’applicazione, della cache e del database prima e dopo un singolo riavvio controllato del proxy.

Docker Compose può riavviare i servizi dipendenti quando una dipendenza è configurata esplicitamente per propagare i riavvii. Le indicazioni ufficiali sull’ordine di avvio mostrano perché un comando descritto come riavvio del proxy potrebbe anche sostituire o riavviare un container di autenticazione o dell’applicazione.

Se solo il proxy riceve un nuovo orario di avvio, concentrati sull’autenticazione, sul routing e sui cookie gestiti dal proxy. Se si riavviano anche l’app, la cache o il gateway di autenticazione, esamina prima la persistenza delle sessioni e i relativi segreti.

Identifica quale livello ha emesso il cookie di accesso

Prima del riavvio, registra il nome, il dominio, il percorso, gli attributi Secure, HttpOnly e SameSite, la scadenza del cookie e verifica se viene impostato dall’applicazione o da un gateway di autenticazione.

MDN spiega che l’ambito e gli attributi del cookie determinano dove il browser lo invia, ma tali attributi non rivelano quale backend ne convalida il valore.

Confronta le intestazioni della risposta della richiesta di accesso con quelle della prima richiesta dopo il riavvio. Un cookie mancante indica un problema di ambito del browser; un cookie invariato rifiutato dal server indica la perdita dello stato, la modifica delle chiavi o un backend diverso.

Verifica se un gateway di autenticazione ha rigenerato il segreto della sessione

Esamina l’origine del segreto del gateway di autenticazione, il montaggio del file, l’ambiente, la ricreazione del container e la configurazione generata. Confronta l’origine del valore prima e dopo il riavvio senza esporre il segreto.

Authelia documenta che il suo segreto della sessione crittografa i dati archiviati, quindi la modifica o la perdita di tale segreto impedisce al servizio di leggere le sessioni create in precedenza.

Archivia i segreti delle sessioni in un file persistente o in un gestore di segreti, invece di generarli a ogni avvio del container. Esegui le rotazioni intenzionalmente, definendo una finestra di disconnessione documentata.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Escludi un archivio delle sessioni in memoria

Identifica se l’applicazione archivia le sessioni nella memoria del processo, in una cache locale, in Redis, in un database o nei cookie firmati lato client. Confronta il tempo di attività del processo che gestisce le sessioni con il momento della disconnessione.

Django avverte che un backend delle sessioni basato esclusivamente sulla cache può perdere i dati delle sessioni quando la cache viene riavviata o svuotata, causando la disconnessione degli utenti quando i dati delle sessioni scompaiono.

Se lo stack del proxy include il container della cache, il riavvio dello stack potrebbe cancellare le sessioni anche se il container dell’applicazione resta attivo. Utilizza una configurazione della cache persistente o un fallback basato sul database quando la continuità degli accessi è importante.

Confronta le chiavi di firma dell’applicazione tra i riavvii

Esamina l’origine della chiave di firma o crittografia delle sessioni dell’applicazione e determina se la chiave è persistente, se viene caricata dal file env previsto o se viene generata all’avvio.

Flask utilizza SECRET_KEY per firmare i cookie di sessione, quindi la sostituzione di questa chiave rende non validi i cookie firmati esistenti anche quando il browser continua a inviarli.

Non risolvere il problema condividendo un unico segreto tra applicazioni non correlate. Assegna a ogni app un segreto stabile, proteggilo come configurazione critica per i backup e verifica che sopravviva alla ricreazione dell’immagine.

Controlla le sessioni persistenti e le modifiche alle repliche backend

Elenca le repliche backend, i relativi archivi delle sessioni e il criterio di bilanciamento del proxy. Verifica se lo stesso utente resta connesso quando le richieste raggiungono un’altra replica.

La configurazione delle sessioni persistenti di Traefik indirizza nuovamente il client verso un backend, ma gli utenti possono comunque perdere la sessione se le repliche non condividono lo stato e un riavvio modifica l’endpoint selezionato.

La persistenza può nascondere un archivio delle sessioni locale configurato in modo errato. Quando sono previste più repliche dell’app, preferisci uno stato delle sessioni condiviso e durevole, in grado di sopravvivere alla sostituzione del proxy o del backend.

Riproduci il problema con un account di prova e una configurazione stabile

Acquisisci una copia della configurazione, accedi con un account usa e getta, registra gli identificatori della sessione, riavvia solo il proxy e verifica la stessa richiesta prima di riavviare qualsiasi altro componente.

L’articolo di ZimaSpace sui loop di accesso che si verificano solo dall’esterno tratta i problemi di accesso dipendenti dal percorso; questo articolo si concentra sull’invalidazione simultanea di sessioni già valide dopo un riavvio.

Il problema è risolto quando i riavvii del solo proxy preservano le sessioni, i riavvii intenzionali dell’autenticazione o dell’app utilizzano segreti stabili e uno stato persistente e ogni replica accetta lo stesso accesso attivo.

Domande frequenti

Un reverse proxy può memorizzare direttamente le sessioni degli utenti?

Può farlo quando include un gateway di autenticazione, un middleware di accesso o un meccanismo di sessione persistente. Un semplice proxy di inoltro di solito non gestisce direttamente la sessione di accesso dell’applicazione.

Il riavvio di Redis disconnette sempre gli utenti?

Solo quando le sessioni esistono esclusivamente in Redis e i relativi dati non vengono persistiti o ripristinati. Le applicazioni che utilizzano sessioni basate sul database o cookie firmati si comportano diversamente.

Devo aumentare la durata del cookie per evitare le disconnessioni dopo un riavvio?

No. Un cookie con durata maggiore continua a non funzionare se la chiave di firma cambia o se il record della sessione lato server scompare. Risolvi prima la persistenza e la stabilità dei segreti.