Distrust: Discourse как провайдер OpenID Connect

Настройка Дополнительно
12

Надеюсь, кто-то из экспертов сможет взглянуть на проблемы, с которыми я столкнулся при попытке использовать Discourse в качестве провайдера SSO.

Моя цель: Я настраиваю Discourse для обработки аутентификации другого приложения (LibreChat). Я использую стандартную функциональность провайдера DiscourseConnect, а в качестве клиента, который взаимодействует с Discourse, выступает сервис OIDC-моста distrust.

Проблема: Процесс SSO работает безупречно до самого последнего шага. Пользователь корректно перенаправляется из моего приложения в Discourse и успешно входит в систему с помощью учетных данных Discourse. Однако после входа его перенаправляют на главную страницу моего форума Discourse (/), а не обратно на предоставленный return_sso_url.

Где я застрял (что я исключил): Я уже давно занимаюсь устранением неполадок и убедился, что это не простая ошибка конфигурации. Я окончательно исключил следующее:

  • Секреты: Секреты discourse connect provider настроены правильно. Я использую домен без протокола (например, auth.my-site.com), и ключ секрета точно совпадает с тем, что используется в моем клиентском сервисе.
  • Режим SSO: Я подтвердил, что включена опция enable discourse connect provider, а неверные настройки «SSO Client» отключены.
  • Политики пользователей: Я убедился, что must_approve_users отключен, а мой тестовый пользователь является администратором с полностью подтвержденным адресом электронной почты.
  • Плагины: Я отключил все неофициальные сторонние плагины и пересобрал контейнер, но проблема сохраняется.

Ключевые доказательства: У меня есть два неопровержимых доказательства, которые меня сбивают с толку:

  1. Анализ HAR-файла: Я записал весь сетевой поток в HAR-файл. Он показывает, что запрос POST к /session для входа в систему успешен. Сервер немедленно отвечает перенаправлением 302 Found, но заголовок Location всегда содержит /. Это доказывает, что Discourse намеренно прерывает перенаправление SSO.
  2. Пустой лог Rails: Затем я отслеживал файл production.log внутри контейнера во время попытки входа. В этот процесс ничего не записывается в лог. Это говорит о том, что Discourse не считает это ошибкой; это преднамеренное, тихое действие.

Мой вопрос: Учитывая, что вход в систему успешен, но перенаправление неверно, и в логах нет ошибок, какая внутренняя политика Discourse, проверка перед выполнением или скрытая настройка могут заставлять его игнорировать return_sso_url и перенаправлять на главную страницу? Мне кажется, что я исчерпал все стандартные настройки.

Заранее спасибо за любые идеи!