Se você manteve sua sessão, não enfrentará nenhum problema. Porém, se tentar fazer login agora, ao clicar em “Entrar”, a URL muda para: /auth/failure?message=csrf_detected e recebemos a mensagem de erro: A autorização expirou ou você trocou de navegador. Por favor, tente novamente..
Alguém sabe se houve alguma mudança recente que possa ter levado a essa situação?
Uma pergunta de passagem: existe alguma forma de reverter para uma versão anterior? Tenho procurado por aí e o consenso é desativar os plugins (ou o plugin específico com problema). No entanto, não consigo desativar este, pois é assim que meus usuários fazem login na plataforma
Não é realmente suportado, mas se você tiver um backup, pode excluir o diretório de dados do PostgreSQL, adicionar um commit na linha de versão no app.yml, reconstruir e restaurar o backup.
Sim, fiz um backup e estou tentando reconstruir usando o SHA da versão que eu tinha, porque ela está funcionando de forma instável.
Paralelamente, ainda tenho a versão latest-stable tentando ver se conseguimos corrigir isso de alguma forma.
Não sei se @david tem algum conselho, como sugerido por @codinghorror, mas estou disposto a tentar qualquer coisa, já que meus usuários estão bloqueados (a menos que tenham mantido a sessão).
Atualização rápida: Tentei usar a versão de backup com um snapshot da máquina naquele momento (antes da atualização). Ao clicar em “Log In”, a página principal recarrega duas vezes. Tentei reconstruir com o commit SHA exato que eu tinha na época, mas não tive sorte; erro no DB Rake.
Tenho procurado por outros relatos sobre o problema do LDAP, mas não parece haver nenhum. Será que isso pode ser causado por uma fonte externa?
Problema resolvido, identificamos a causa raiz, não está relacionada ao Discourse (desculpem, pessoal!). O problema era que o Certificado foi atualizado e servido através de um HAP. Antes não estávamos usando um HAP e o Discourse o servia diretamente; esquecemos desse detalhe, o que resultou no erro de CORS.
Lições aprendidas:
Reverter o Discourse não é uma opção; é melhor ter um backup de toda a máquina (felizmente, foi o nosso caso).
Ainda estou descobrindo por que foi tão difícil reconstruir com um SHA específico seguindo as instruções que li aqui; não consegui fazer isso.
É melhor sempre servir os certificados pelo HAP, mas não se esqueça disso. (Como uma nota para qualquer outra pessoa, é necessário adicionar a flag 'set-header X-Forwarded-Proto https' porque o Discourse tem seu próprio NGINX, e foi aí que ocorreu a falha).
O fato de ninguém ter relatado o mesmo problema (mesmo considerando que este é um caso de canto, já que o plugin não é oficial) apontou nessa direção (Comunidade como planejado :P).
O problema só se manifestou tardiamente (a ponto de não lembrarmos da mudança no Certificado) por causa da reconstrução acionada pela atualização, momento em que a falha ocorreu.
