Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Le redémarrage d’un proxy inverse déconnecte tous les utilisateurs uniquement lorsqu’il modifie, perd ou réachemine également l’état de session utilisé par l’application.
Un proxy de base transmet généralement les cookies sans gérer la session de l’application. Son redémarrage seul ne devrait donc pas invalider toutes les connexions. Le véritable déclencheur peut être le redémarrage d’une passerelle d’authentification, la régénération d’un secret de signature des cookies, un cache de sessions en mémoire, un changement de réplique backend ou une dépendance Compose qui redémarre l’application avec le proxy. Identifiez le composant qui a émis et valide la session avant de modifier les attributs des cookies ou de forcer les utilisateurs à se reconnecter.
Confirmez quels services ont redémarré avec le proxy
Notez les identifiants des conteneurs, les heures de démarrage, le nombre de redémarrages, les événements d’état de santé et les journaux du proxy inverse, du service d’authentification, de l’application, du cache et de la base de données avant et après un redémarrage contrôlé du proxy.
Docker Compose peut redémarrer les services dépendants lorsqu’une propagation explicite des redémarrages est configurée pour une dépendance. Les instructions officielles sur l’ordre de démarrage expliquent pourquoi une commande décrite comme un redémarrage du proxy peut également remplacer ou redémarrer un conteneur d’authentification ou d’application.
Si seul le proxy reçoit une nouvelle heure de démarrage, concentrez-vous sur l’authentification, le routage et les cookies gérés par le proxy. Si l’application, le cache ou la passerelle d’authentification redémarre également, examinez d’abord la persistance de leurs sessions et leurs secrets.
Identifiez la couche qui a émis le cookie de connexion
Avant le redémarrage, notez le nom, le domaine, le chemin, les attributs Secure, HttpOnly et SameSite, la date d’expiration du cookie, ainsi que l’élément qui le définit : l’application ou une passerelle d’authentification.
MDN explique que la portée et les attributs d’un cookie déterminent où le navigateur l’envoie, mais ces attributs n’indiquent pas quel backend valide sa valeur.
Comparez les en-têtes de réponse de la requête de connexion et de la première requête effectuée après le redémarrage. Un cookie manquant indique un problème de portée côté navigateur ; un cookie inchangé rejeté par le serveur indique une perte d’état, une modification des clés ou un autre backend.
Vérifiez si une passerelle d’authentification a régénéré son secret de session
Examinez la source du secret de la passerelle d’authentification, le montage du fichier, l’environnement, la recréation du conteneur et la configuration générée. Comparez la source de la valeur avant et après le redémarrage sans exposer le secret lui-même.
Authelia précise que son secret de session chiffre les données de session stockées. Modifier ou perdre ce secret empêche donc le service de lire les sessions créées précédemment.
Stockez les secrets de session dans un fichier de secrets persistant ou dans un gestionnaire de secrets, plutôt que de les générer au démarrage de chaque conteneur. Effectuez les rotations volontairement, avec une période de déconnexion documentée.
Écartez l’hypothèse d’un stockage des sessions en mémoire
Déterminez si l’application stocke les sessions en mémoire dans le processus, dans un cache local, dans Redis, dans une base de données ou dans des cookies client signés. Comparez la durée de fonctionnement du processus de stockage des sessions avec le moment de la déconnexion.
Django avertit qu’un backend de sessions reposant uniquement sur le cache peut perdre les données de session lorsque le cache redémarre ou expulse des entrées, ce qui déconnecte les utilisateurs lorsque les données de session disparaissent.
Si la pile du proxy inclut le conteneur de cache, le redémarrage de cette pile peut effacer les sessions même si le conteneur de l’application reste actif. Utilisez une configuration de cache persistante ou une solution de secours reposant sur une base de données lorsque la continuité des connexions est importante.
Comparez les clés de signature de l’application entre les redémarrages
Examinez la source de la clé de signature ou de chiffrement des sessions de l’application et vérifiez si la clé est persistante, chargée depuis le fichier d’environnement attendu ou générée au démarrage.
Flask utilise SECRET_KEY pour signer les cookies de session. Remplacer cette clé rend donc les cookies signés existants invalides, même si le navigateur continue de les envoyer.
Ne résolvez pas ce problème en partageant un même secret entre des applications indépendantes. Attribuez à chaque application un secret stable, protégez-le comme une configuration essentielle aux sauvegardes et vérifiez qu’il subsiste après la recréation de l’image.
Vérifiez les sessions persistantes et les changements de réplique backend
Répertoriez les répliques backend, leurs stockages de sessions et la stratégie d’équilibrage de charge du proxy. Vérifiez si le même utilisateur reste connecté lorsque les requêtes sont dirigées vers une autre réplique.
La configuration des sessions persistantes de Traefik redirige un client vers le même backend, mais les utilisateurs peuvent tout de même perdre leur session si les répliques ne partagent pas leur état et si un redémarrage modifie le point de terminaison sélectionné.
Les sessions persistantes peuvent masquer un stockage local des sessions mal configuré. Préférez un état de session partagé et durable lorsque plusieurs répliques de l’application doivent rester opérationnelles après le remplacement du proxy ou du backend.
Reproduisez le problème avec un seul compte de test et une configuration stable
Figez la configuration, connectez-vous avec un compte jetable, notez les identifiants de session, redémarrez uniquement le proxy et testez la même requête avant de redémarrer un autre composant.
L’article de ZimaSpace sur les boucles de connexion uniquement à l’extérieur du réseau domestique traite des échecs de connexion dépendant du chemin réseau ; cet article se concentre sur l’invalidation simultanée de sessions déjà valides après un redémarrage.
Le problème est résolu lorsque les redémarrages du proxy seul préservent les sessions, que les redémarrages délibérés de l’authentification ou de l’application utilisent des secrets stables et un état persistant, et que chaque réplique accepte la même connexion active.
Foire aux questions
Un proxy inverse peut-il stocker lui-même les sessions utilisateur ?
Oui, lorsqu’il inclut une passerelle d’authentification, un middleware de contrôle d’accès ou un mécanisme de sessions persistantes. Un simple proxy de transmission ne gère généralement pas la session de connexion de l’application.
Le redémarrage de Redis déconnecte-t-il toujours les utilisateurs ?
Seulement lorsque les sessions existent uniquement dans Redis et que ses données ne sont ni conservées ni restaurées. Les applications utilisant des sessions stockées dans une base de données ou des cookies signés se comportent différemment.
Dois-je augmenter la durée de vie du cookie pour éviter les déconnexions après un redémarrage ?
Non. Même un cookie ayant une durée de vie plus longue échoue si sa clé de signature change ou si son enregistrement de session côté serveur disparaît. Corrigez d’abord la persistance et la stabilité des secrets.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi un alias réseau Compose cesse-t-il d’être résolu après la recréation de la stack sous un nouveau nom de projet ?
Un diagnostic DNS de Compose couvrant les noms de projet, les alias associés aux réseaux, les réseaux externes, le DNS intégré, la connexion du...
