Até onde eu sei, o mesmo problema foi mencionado duas vezes e foi dito que foi corrigido em 2018 (Discourse doesn't redirect to return_sso_url after user logs in on private site) e em 2015 (Login redirect during sso provider login). No entanto, ainda estou enfrentando o mesmo problema.
Instalei o Discourse em nossa organização. Temos nosso próprio banco de dados de contas de usuários, então usamos nosso site de login SSO personalizado para permitir que os usuários façam login no Discourse, seguindo as instruções em Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Funciona bem.
Além disso, temos WordPress, Rocket Chat e um aplicativo web Tornado personalizado. Eles dependem do Discourse como provedor de SSO.
Para o WordPress, estamos usando o wp-discourse. Para o Rocket Chat e o aplicativo web Tornado, seguimos as instruções em Use Discourse as an identity provider (SSO, DiscourseConnect).
O fluxo de login funcionou bem se o usuário já tivesse feito login no Discourse. No entanto, se o usuário ainda não tivesse feito login no Discourse, nenhum dos fluxos de login dos serviços (por exemplo, WordPress/Rocket Chat/aplicativo web Tornado) funcionou corretamente. Quando um usuário tenta fazer login no WordPress, Rocket Chat ou no aplicativo web Tornado, eles são redirecionados para discourse.com/login. Em seguida, o usuário clica no botão de login, que o redireciona para nosso site SSO personalizado. Lá, eles realizam o login e, em seguida, são redirecionados para discourse.com, mas não para o serviço desejado (por exemplo, WordPress, Rocket Chat ou aplicativo web Tornado).
Apenas um desvio: a função de Sincronização de Logout com Discourse do wp-discourse não funciona. Quando um usuário faz logout do WordPress, eles permanecem logados no Discourse.
Tenho enfrentado esse problema há vários meses após várias atualizações do Discourse. Agora estou buscando ajuda. Por favor, avise se forem necessários mais detalhes.
Meu workaround atual é redirecionar o usuário para /session/sso?return_path=customurl em vez de /session/sso_provider. A desvantagem é que sempre pede ao usuário para fazer login, mesmo que ele já esteja logado no Discourse.