Провайдер SSO для Discourse не перенаправляет на return_sso_url при входе пользователя через кастомный SSO

Поддержка SSO
1

Насколько мне известно, о той же проблеме упоминалось дважды, и утверждалось, что она была исправлена в 2018 году (Discourse doesn't redirect to return_sso_url after user logs in on private site) и в 2015 году (Login redirect during sso provider login). Однако я всё ещё сталкиваюсь с той же проблемой.

В нашей организации установлен Discourse. У нас есть собственная база данных учётных записей пользователей, поэтому мы используем наш собственный сайт входа через SSO для предоставления пользователям возможности входа в Discourse, следуя инструкциям по адресу Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). Это работает хорошо.

Кроме того, у нас есть WordPress, Rocket Chat и собственное веб-приложение на Tornado. Они используют Discourse в качестве провайдера SSO.

Для WordPress мы используем плагин wp-discourse. Для Rocket Chat и веб-приложения на Tornado мы следовали инструкциям по адресу Use Discourse as an identity provider (SSO, DiscourseConnect).

Процесс входа работал корректно, если пользователь уже был авторизован в Discourse. Однако, если пользователь ещё не входил в Discourse, процесс входа ни в одном из сервисов (например, WordPress, Rocket Chat или веб-приложение на Tornado) не работал должным образом. Когда пользователь пытается войти в WordPress, Rocket Chat или веб-приложение на Tornado, его перенаправляют на discourse.com/login. Затем пользователь нажимает кнопку входа, что перенаправляет его на наш собственный сайт SSO. Там он выполняет вход, после чего его перенаправляют на discourse.com, но не на нужный сервис (например, WordPress, Rocket Chat или веб-приложение на Tornado).

Небольшое отступление: функция wp-discourse «Синхронизация выхода из системы с Discourse» не работает. Когда пользователь выходит из WordPress, он остаётся авторизованным в Discourse.

Я сталкиваюсь с этой проблемой уже несколько месяцев после нескольких обновлений Discourse. Теперь я обращаюсь за помощью. Пожалуйста, сообщите, если потребуются дополнительные детали.

Мой текущий обходной путь заключается в том, чтобы перенаправлять пользователя не на /session/sso_provider, а на /session/sso?return_path=customurl. Недостаток этого решения заключается в том, что система всегда запрашивает вход у пользователя, даже если он уже авторизован в Discourse.

2

Во время кастомного входа через SSO приложение входа фактически прочитало и извлекло return_sso_url из cookie sso_payload. Этот return_sso_url внедрён в payload sso для отправки на /session/sso_login?. Я мог наблюдать в /logs, что return_sso_url был установлен корректно, но перенаправление не произошло. Ниже я привожу лог:

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:

3

@cylau1996 ты нашёл какое-нибудь решение?

4

Есть какое-то решение по этому вопросу?