Provedor SSO do Discourse não redireciona para return_sso_url quando o usuário faz login com SSO personalizado

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.

2 curtidas

Durante o login personalizado via SSO, o aplicativo de login realmente leu e extraiu o return_sso_url do cookie sso_payload. Esse return_sso_url está embutido no payload sso para ser enviado para /session/sso_login?. Na verdade, pude observar nos logs que o return_sso_url estava configurado corretamente, mas a redireção não foi registrada. Abaixo, estou colando o log:

add_groups:
admin:
moderator:
avatar_force_update:
avatar_url:
bio:
card_background_url:
email: xxx@xxx
external_id: 42
groups:
locale:
locale_force_update:
logout:
name: xxx
nonce: b4c758723a8abf665b079dc41a585dbc
profile_background_url:
remove_groups:
require_activation:
return_sso_url: https://customurl
suppress_welcome_message:
title:
username: xxx
website:
location:

1 curtida

@cylau1996 você encontrou alguma solução?

Alguma solução para isso?