Após uma reconstrução hoje com 3.3.3 (a versão estável mais recente lançada há alguns dias), o SSO parou de funcionar. Usuários já logados continuam funcionando por enquanto, mas novas sessões encerram o fluxo do SSO com o erro:
O login da conta expirou, por favor, tente logar novamente.
Log detalhado do SSO: Nonce incorreto, foi gerado em uma sessão de navegador diferente ou expirou
No entanto, nada em nosso fluxo de SSO mudou nos últimos anos. Os relógios entre os servidores estão sincronizados.
Por outro lado, atualizamos muito recentemente para 3.3.3 (de 3.3.2), que possui correções de segurança relacionadas ao Discourse Connect, o que pode ser relevante.
Pouco provável que seja relevante, mas a reconstrução foi para habilitar um CDN. Mas, eu já reverti todas essas alterações e o problema do SSO permanece.
Após várias reconstruções, consegui fazer o SSO funcionar novamente fixando-o de volta à v3.3.2, então parece que algo foi introduzido na v3.3.3 que quebrou o suporte ao SSO.
Eu dei uma olhada superficial em um git diff v3.3.2 v3.3.3 e nada óbvio se destacou, mas ele tem mudanças relacionadas ao Discourse Connect.
No entanto, suspeito que isso começará a afetar mais pessoas à medida que elas atualizam para a 3.3.3 e as sessões de usuário começam a expirar e falham ao serem renovadas. Talvez valha a pena uma análise mais detalhada por alguém que conheça o código, especialmente o fluxo de SSO? /cc @sam
PS: Não tenho certeza se pode ser relevante: atualizei para a 3.3.3 há mais de um dia, mas os problemas parecem ter surgido logo após uma reconstrução via console há algumas horas (para habilitar um CDN, mas reverter isso não corrigiu o SSO).
Sim, no sentido de que a maioria das pessoas executa o branch tests-passed, mas não no sentido de que esta é a versão mais recente do branch estável, lançada esta semana: 3.3.3: Security and maintenance release
É um tiro no escuro, mas você está gerando o nonce em uma sessão de navegador diferente, por exemplo, fazendo as solicitações de SSO pelo backend do seu aplicativo, em vez de fazer os usuários passarem pelo processo de SSO usando redirecionamentos do navegador?
Existe uma configuração oculta do site chamada discourse_connect_csrf_protection que está habilitada por padrão. Para permitir que as solicitações de SSO sejam feitas de fora da sessão de um usuário, ela precisa ser desabilitada.
Estou assumindo que essa configuração estava em vigor na versão 3.3.2, mas possivelmente foi adicionada depois.
Embora não estejamos fazendo nada incomum com o SSO, eu tentei isso de qualquer maneira desabilitando-o no console Rails e tudo o que fez foi remover a mensagem de erro, no sentido de que quando o provedor de SSO redirecionava de volta para o Discourse, em vez do erro A sessão de login expirou, por favor, tente fazer login novamente., não havia mensagem alguma (erro ou outra) – mas, infelizmente, ainda deslogado.
Estou também agarrando palha aqui, pois isso é bastante estranho. Acho que o fato de o problema não ter aparecido quando atualizamos inicialmente para 3.3.3 pela interface web, mas apenas (~36h) depois de uma reconstrução do console pode ser uma pista, mas não sei o suficiente sobre as diferenças entre os dois.
Tentei atualizar novamente para 3.3.3 e o problema retornou imediatamente. Voltar para 3.3.2 fez o SSO funcionar novamente.
Suspeito que o problema aqui não seja a correção de segurança do DiscourseConnect, mas sim a alteração do nginx. Em tests-passed, tivemos que fazer um acompanhamento na quinta-feira porque estava causando problemas em alguns ambientes e outro usuário no Github notou problemas de CSRF.
Fico feliz em relatar que isso resolveu o problema!
Agradeço por ter dedicado tempo para analisar isso, especialmente em um fim de semana e considerando que tanto stable quanto SSO são um pouco nichados, mas espero que ajude outras pessoas também. Obrigado!
