¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un reinicio del proxy inverso cierra la sesión de todos los usuarios solo cuando también cambia, pierde o redirige el estado de sesión utilizado por esa aplicación.
Un proxy básico normalmente reenvía las cookies en lugar de administrar la sesión de la aplicación, por lo que un reinicio del proxy por sí solo no debería invalidar todos los inicios de sesión. El desencadenante real puede ser un gateway de autenticación reiniciado, un secreto de firma de cookies regenerado, una caché de sesiones en memoria, un cambio de réplica del backend o una dependencia de Compose que reinicia la aplicación junto con el proxy. Identifica qué componente emitió y valida la sesión antes de cambiar los atributos de las cookies u obligar a los usuarios a iniciar sesión de nuevo.
Confirma qué servicios se reiniciaron junto con el proxy
Registra los ID de los contenedores, las horas de inicio, los recuentos de reinicios, los eventos de estado y los registros del proxy inverso, el servicio de autenticación, la aplicación, la caché y la base de datos antes y después de un reinicio controlado del proxy.
Docker Compose puede reiniciar servicios dependientes cuando una dependencia está configurada explícitamente para propagar los reinicios. La guía oficial sobre el orden de inicio muestra por qué un comando descrito como un reinicio del proxy también puede reemplazar o reiniciar un contenedor de autenticación o de la aplicación.
Si solo el proxy recibe una nueva hora de inicio, céntrate en la autenticación, el enrutamiento y las cookies administrados por el proxy. Si la aplicación, la caché o el gateway de autenticación también se reinician, inspecciona primero la persistencia de sus sesiones y sus secretos.
Identifica qué capa emitió la cookie de inicio de sesión
Antes de reiniciar, registra el nombre de la cookie, el dominio, la ruta, los atributos Secure, HttpOnly y SameSite, la caducidad y si la establece la aplicación o un gateway de autenticación.
MDN explica que el alcance y los atributos de las cookies determinan cuándo las envía el navegador, pero esos atributos no revelan qué backend valida su valor.
Compara las cabeceras de respuesta de la solicitud de inicio de sesión y de la primera solicitud después del reinicio. Una cookie ausente indica un problema de alcance en el navegador; una cookie sin cambios que el servidor rechaza apunta a un estado perdido, claves modificadas o un backend diferente.
Comprueba si un gateway de autenticación regeneró su secreto de sesión
Inspecciona el origen del secreto del gateway de autenticación, el montaje del archivo, el entorno, la recreación del contenedor y la configuración generada. Compara el origen del valor antes y después del reinicio sin exponer el secreto.
Authelia documenta que su secreto de sesión cifra los datos de sesión almacenados en Redis, por lo que cambiarlo o perderlo impide que el servicio lea las sesiones creadas anteriormente.
Almacena los secretos de sesión en un archivo de secretos persistente o en un almacén de secretos administrado, en lugar de generarlos durante el inicio de cada contenedor. Rótalos deliberadamente con una ventana de cierre de sesión documentada.
Descarta un almacén de sesiones en memoria
Identifica si la aplicación almacena las sesiones en la memoria del proceso, una caché local, Redis, una base de datos o cookies de cliente firmadas. Compara el tiempo de actividad del proceso que almacena las sesiones con el momento en que se cerraron las sesiones.
Django advierte que un backend de sesiones basado únicamente en caché puede perder los datos de sesión cuando la caché se reinicia o se desalojan sus entradas, lo que cierra la sesión de los usuarios cuando desaparecen los datos de sesión.
Si la pila del proxy incluye el contenedor de la caché, reiniciar esa pila puede borrar las sesiones aunque el contenedor de la aplicación siga activo. Utiliza una configuración de caché persistente o un respaldo basado en base de datos cuando sea importante mantener la continuidad del inicio de sesión.
Compara las claves de firma de la aplicación entre reinicios
Inspecciona el origen de la clave de firma o cifrado de sesiones de la aplicación y determina si la clave persiste, se carga desde el archivo de entorno esperado o se genera durante el inicio.
Flask utiliza SECRET_KEY para firmar las cookies de sesión, por lo que reemplazar esa clave invalida las cookies firmadas existentes incluso cuando el navegador sigue enviándolas.
No soluciones esto compartiendo un mismo secreto entre aplicaciones no relacionadas. Asigna a cada aplicación un secreto estable, protégelo como una configuración crítica para las copias de seguridad y verifica que sobreviva a la recreación de la imagen.
Comprueba las sesiones persistentes y los cambios de réplica del backend
Enumera las réplicas del backend, sus almacenes de sesiones y la política de equilibrio de carga del proxy. Comprueba si el mismo usuario mantiene la sesión cuando las solicitudes llegan a otra réplica.
La configuración de sesiones persistentes de Traefik dirige al cliente de nuevo a un backend, pero los usuarios pueden perder la sesión si las réplicas no comparten el estado y un reinicio cambia el endpoint seleccionado.
La persistencia puede ocultar un almacén de sesiones local configurado incorrectamente. Prefiere un estado de sesión compartido y duradero cuando se espera que varias réplicas de la aplicación sobrevivan al reemplazo del proxy o del backend.
Reproduce el problema con una cuenta de prueba y una configuración estable
Guarda una instantánea de la configuración, inicia sesión con una cuenta desechable, registra los identificadores de sesión, reinicia solo el proxy y prueba la misma solicitud antes de reiniciar cualquier otro componente.
El artículo de ZimaSpace sobre los bucles de inicio de sesión solo desde fuera de la red aborda los fallos de inicio de sesión dependientes de la ruta; este artículo se centra en la invalidación simultánea de sesiones que ya eran válidas después de un reinicio.
El problema se resuelve cuando los reinicios exclusivos del proxy conservan las sesiones, los reinicios deliberados de la autenticación o la aplicación utilizan secretos estables y un estado persistente, y todas las réplicas aceptan el mismo inicio de sesión activo.
Preguntas frecuentes
¿Puede un proxy inverso almacenar las sesiones de los usuarios?
Puede hacerlo cuando incluye un gateway de autenticación, un middleware de acceso o un mecanismo de sesiones persistentes. Un proxy de reenvío simple normalmente no administra la sesión de inicio de sesión de la aplicación.
¿Reiniciar Redis siempre cierra la sesión de los usuarios?
Solo cuando las sesiones existen únicamente en Redis y sus datos no se conservan ni se restauran. Las aplicaciones que utilizan sesiones respaldadas por una base de datos o cookies firmadas se comportan de otra manera.
¿Debo aumentar la duración de las cookies para evitar que los reinicios cierren las sesiones?
No. Una cookie de mayor duración seguirá fallando si cambia su clave de firma o desaparece su registro de sesión del servidor. Corrige primero la persistencia y la estabilidad de los secretos.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué un alias de red de Compose deja de resolverse después de recrear la pila con un nombre de proyecto nuevo?
Un diagnóstico de DNS de Compose que abarca los nombres de proyecto, los alias con ámbito de red, las redes externas, el DNS integrado,...
