Если вы когда-нибудь хотели использовать Discourse в качестве провайдера аутентификации — теперь это возможно!
За последнюю неделю я написал небольшой сервис, который может выступать в роли провайдера OpenID Connect/OAuth с использованием Discourse в качестве бэкенда.
Вы можете ознакомиться с кодом здесь:
Обратите внимание, что моим основным сценарием использования была аутентификация в Nextcloud через Discourse, поэтому сервис может не подходить для ваших задач.
Если что-то работает не так, как ожидалось, или отсутствует та самая функция, необходимая для вашей работы, не стесняйтесь создать issue в репозитории GitHub.
Отличная инициатива! Я всегда хотел, чтобы Discourse можно было использовать в качестве провайдера OAuth, чтобы его можно было легко интегрировать с другими инструментами. Превращение его во внешний небольшой сервис также имеет большой смысл!
Мне нравится эта идея, и я надеюсь, что некоторые сообщества решат её опробовать!
Мне бы очень хотелось, чтобы OIDC официально поддерживался в Discourse в дополнение к нашему собственному функционалу Discourse Connect. Это позволит нам предлагать клиентам на тарифах Standard и Teams готовое решение, не полагаясь на Okta или подобные сервисы.
Distrust — это отдельный сервис, поэтому его нужно разворачивать как таковой. Вы можете запустить его в контейнере, как описано в файле README. Обратите внимание, что для безопасной работы вам также потребуется обратный прокси-сервер, осуществляющий SSL-терминацию (возможно, в будущем я реализую это напрямую).
Надеюсь, кто-то из экспертов сможет взглянуть на проблемы, с которыми я столкнулся при попытке использовать 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 отключен, а мой тестовый пользователь является администратором с полностью подтвержденным адресом электронной почты.
Плагины: Я отключил все неофициальные сторонние плагины и пересобрал контейнер, но проблема сохраняется.
Ключевые доказательства: У меня есть два неопровержимых доказательства, которые меня сбивают с толку:
Анализ HAR-файла: Я записал весь сетевой поток в HAR-файл. Он показывает, что запрос POST к /session для входа в систему успешен. Сервер немедленно отвечает перенаправлением 302 Found, но заголовок Location всегда содержит /. Это доказывает, что Discourse намеренно прерывает перенаправление SSO.
Пустой лог Rails: Затем я отслеживал файл production.log внутри контейнера во время попытки входа. В этот процесс ничего не записывается в лог. Это говорит о том, что Discourse не считает это ошибкой; это преднамеренное, тихое действие.
Мой вопрос: Учитывая, что вход в систему успешен, но перенаправление неверно, и в логах нет ошибок, какая внутренняя политика Discourse, проверка перед выполнением или скрытая настройка могут заставлять его игнорировать return_sso_url и перенаправлять на главную страницу? Мне кажется, что я исчерпал все стандартные настройки.
