Porque é que reiniciar um proxy reverso invalida todas as sessões de uma aplicação auto-hospedada?
Um reinício do proxy inverso termina a sessão de todos os utilizadores apenas quando também altera, perde ou redireciona o estado da sessão utilizado por essa aplicação.
Um proxy básico normalmente reencaminha cookies em vez de gerir a sessão da aplicação, pelo que um reinício isolado do proxy não deverá invalidar todas as sessões iniciadas. O verdadeiro desencadeador pode ser um gateway de autenticação reiniciado, um segredo de assinatura de cookies regenerado, uma cache de sessões em memória, uma alteração de réplica no backend ou uma dependência do Compose que reinicia a aplicação juntamente com o proxy. Identifique qual o componente que emitiu e valida a sessão antes de alterar os atributos dos cookies ou de obrigar os utilizadores a iniciar sessão novamente.
Confirme quais os serviços que foram reiniciados com o proxy
Registe os IDs dos contentores, as horas de início, as contagens de reinícios, os eventos de estado e os registos do proxy inverso, do serviço de autenticação, da aplicação, da cache e da base de dados antes e depois de um reinício controlado do proxy.
O Docker Compose pode reiniciar serviços dependentes quando uma dependência está explicitamente configurada para propagar reinícios. A orientação oficial sobre a ordem de arranque explica por que motivo um comando descrito como reinício do proxy também pode substituir ou reiniciar um contentor de autenticação ou da aplicação.
Se apenas o proxy receber uma nova hora de início, concentre-se na autenticação, no encaminhamento e nos cookies geridos pelo proxy. Se a aplicação, a cache ou o gateway de autenticação também forem reiniciados, analise primeiro a persistência das sessões e os respetivos segredos.
Identifique a camada que emitiu o cookie de início de sessão
Antes de reiniciar, registe o nome, o domínio, o caminho, os atributos Secure, HttpOnly e SameSite, a validade do cookie e se este é definido pela aplicação ou por um gateway de autenticação.
A MDN explica que o âmbito e os atributos do cookie determinam onde o navegador o envia, mas esses atributos não revelam qual o backend que valida o seu valor.
Compare os cabeçalhos de resposta do pedido de início de sessão e do primeiro pedido após o reinício. A ausência do cookie indica um problema de âmbito no navegador; um cookie inalterado rejeitado pelo servidor aponta para perda de estado, alteração de chaves ou utilização de um backend diferente.
Verifique se um gateway de autenticação regenerou o segredo da sessão
Analise a origem do segredo do gateway de autenticação, a montagem do ficheiro, o ambiente, a recriação do contentor e a configuração gerada. Compare a origem do valor antes e depois do reinício sem expor o próprio segredo.
A Authelia documenta que o seu segredo de sessão encripta os dados de sessão armazenados, pelo que alterar ou perder esse segredo impede o serviço de ler as sessões criadas anteriormente.
Armazene os segredos de sessão num ficheiro persistente ou num repositório de segredos gerido, em vez de os gerar durante cada arranque do contentor. Faça a rotação de forma deliberada, com uma janela de encerramento de sessões documentada.
Exclua a utilização de um armazenamento de sessões em memória
Identifique se a aplicação armazena as sessões na memória do processo, numa cache local, no Redis, numa base de dados ou em cookies do cliente assinados. Compare o tempo de atividade do processo que gere as sessões com o momento em que as sessões foram terminadas.
O Django alerta para o facto de um backend de sessões baseado apenas em cache poder perder dados de sessão quando a cache é reiniciada ou os dados são expulsos, o que termina a sessão dos utilizadores quando os dados da sessão desaparecem.
Se a pilha do proxy incluir o contentor da cache, reiniciar essa pilha pode apagar as sessões mesmo que o contentor da aplicação continue ativo. Utilize uma configuração de cache persistente ou uma alternativa baseada numa base de dados quando for importante manter as sessões iniciadas.
Compare as chaves de assinatura da aplicação entre reinícios
Analise a origem da chave de assinatura ou encriptação das sessões da aplicação e determine se a chave é persistente, carregada a partir do ficheiro de ambiente esperado ou gerada no arranque.
O Flask utiliza a SECRET_KEY para assinar cookies de sessão, pelo que substituir essa chave torna inválidos os cookies assinados existentes, mesmo quando o navegador continua a enviá-los.
Não resolva este problema partilhando um único segredo entre aplicações não relacionadas. Atribua a cada aplicação um segredo estável, proteja-o como configuração crítica para cópias de segurança e confirme que sobrevive à recriação da imagem.
Verifique as sessões persistentes e as alterações às réplicas do backend
Enumere as réplicas do backend, os respetivos armazenamentos de sessões e a política de balanceamento de carga do proxy. Teste se o mesmo utilizador continua com a sessão iniciada quando os pedidos chegam a outra réplica.
A configuração de sessões persistentes do Traefik encaminha um cliente novamente para um backend, mas os utilizadores podem continuar a perder as sessões se as réplicas não partilharem o estado e um reinício alterar o endpoint selecionado.
A persistência pode ocultar um armazenamento de sessões local configurado incorretamente. Prefira um estado de sessão partilhado e durável quando se pretende que várias réplicas da aplicação sobrevivam à substituição do proxy ou do backend.
Reproduza o problema com uma conta de teste e uma configuração estável
Faça uma cópia da configuração, inicie sessão com uma conta descartável, registe os identificadores da sessão, reinicie apenas o proxy e teste o mesmo pedido antes de reiniciar qualquer outro componente.
O artigo da ZimaSpace sobre ciclos de início de sessão apenas no exterior aborda falhas de início de sessão dependentes do caminho; este artigo centra-se na invalidação simultânea de sessões que já eram válidas após um reinício.
O problema fica resolvido quando os reinícios apenas do proxy preservam as sessões, os reinícios deliberados da autenticação ou da aplicação utilizam segredos estáveis e estado persistente, e todas as réplicas aceitam o mesmo início de sessão ativo.
Perguntas frequentes
Um proxy inverso pode armazenar as sessões dos utilizadores?
Pode, quando inclui um gateway de autenticação, middleware de controlo de acesso ou um mecanismo de sessões persistentes. Um proxy simples de reencaminhamento normalmente não gere a sessão de início de sessão da aplicação.
Reiniciar o Redis termina sempre as sessões dos utilizadores?
Apenas quando as sessões existem exclusivamente no Redis e os respetivos dados não são persistidos nem restaurados. As aplicações que utilizam sessões baseadas numa base de dados ou em cookies assinados comportam-se de forma diferente.
Devo aumentar a validade do cookie para impedir que os reinícios terminem as sessões?
Não. Um cookie com validade mais longa continua a falhar se a respetiva chave de assinatura mudar ou se o registo da sessão no servidor desaparecer. Corrija primeiro a persistência e a estabilidade dos segredos.
Produtos recomendados
Suporte e Dicas
Mais para Ler
Por que motivo o restauro de um volume Docker recria o conteúdo dos ficheiros, mas elimina os atributos estendidos?
Um diagnóstico da restauração de volumes que abrange o inventário de xattr, as opções do tar e do Rsync, os namespaces, o suporte do...
Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?
Um diagnóstico dos limites de memória que abrange cgroups ativos, reinício versus recriação, campos do Compose, limites rígidos e flexíveis, âmbitos superiores, swap e...
Porque é que um alias de rede do Compose deixa de ser resolvido depois de a stack ser recriada com um novo nome de projeto?
Um diagnóstico de DNS do Compose que abrange nomes de projetos, aliases com âmbito de rede, redes externas, DNS incorporado, ligação do proxy, endpoints...
