Я унаследовал ответственность за хостинг нашего форума, и, похоже, он ранее был настроен с использованием Discourse Connect. Я не понимаю эту конфигурацию, и прочтение доступной документации пока не прояснило ситуацию.
Мне непонятно, является ли это просто устаревшей конфигурацией (в таком случае я хотел бы её очистить) или же форум одновременно выступает и клиентом, и сервером аутентификации Discourse Connect? Пока я не разберусь в этом лучше, я слишком напуган, чтобы что-либо менять, так как не хочу потерять доступ. В посте о Discourse Connect есть эта важная деталь о переходе от единого входа (SSO).
Если я правильно понимаю, то при отключении Discourse Connect я заставлю каждого пользователя сбрасывать свой пароль?
Я собираюсь поделиться как можно большей частью своей конфигурации, которую считаю безопасной для публикации, чтобы предоставить контекст. Мне кажется… что, возможно, Discourse Connect настроен одновременно и как провайдер, и как клиент потока аутентификации, и это сбивает меня с толку.
Если кто-то готов/способен помочь мне разобраться в этом, я буду очень признателен. Я не хочу вываливать кучу логов в пост поддержки, но могу предоставить дополнительную информацию (включая логи) по запросу.
Моя цель:
глубже понять, как сейчас работает наша аутентификация;
упростить пользователям смену электронных адресов и других настроек учётной записи, так как сейчас я вынужден направлять их просто на создание новой учётной записи;
открыть путь к смене источника истины для нашего SSO.
Если вы хотите получить помощь от человека, который может войти на ваш сайт и помочь разобраться в ситуации, вы можете обратиться ко мне или задать вопрос в канале Marketplace. Информация о моём контракте указана в моём профиле.
Однако, если вы используете Discourse Connect, то при входе в систему пользователей будет перенаправлять на другой сайт для авторизации. Если это ваш случай и вы хотите войти напрямую в Discourse, то да — пользователям придётся установить пароль.
Это очень щедро с вашей стороны, @pfaffman, но, к сожалению, у меня нет бюджета.
После публикации я нашёл в рекомендуемых статьях этот пост от 2019 года: Disable DiscourseConnect. Он полезен благодаря чёткому описанию процесса, но у меня всё ещё отсутствует базовое понимание того, как это работает сейчас.
Я довольно уверен, что перенаправление входа не происходит. Страница входа выглядит как стандартный процесс входа в Discourse с множеством специфичных для Discourse ресурсов, экспортеров данных, скриптов и даже ссылкой на консоль с указанием конкретного коммита нашего форума.
Это заставляет меня быть уверенным в том, что Discourse выступает в качестве собственного источника истины для аутентификации.
Что я пока не до конца понимаю, так это то, как и почему конфигурация DiscourseConnect установлена на переопределение электронной почты, имени пользователя и т. д. из внешнего сайта, но при этом также включена конечная точка /session/sso_provider? Разве это не похоже на то, что Discourse одновременно отказывается от ответственности за вход в систему и при этом выступает в качестве источника истины? Или я упускаю какое-то ключевое понимание или документацию о том, как работает SSO в DiscourseConnect?
Если вас не перенаправляет на внешний сервер SSO, то это не имеет значения, и вы не используете SSO. Является ли сайт публичным?
Если вы не входите в систему через то, что указано в скрытом URL-адресе Discourse Connect, то у вас нет никакой проблемы.
Подождите. Вы не показываете опцию «Включить Discourse Connect». Я подозреваю, что она не включена, и именно поэтому её не видно, когда у вас включено «Показывать только переопределения».
Так что, раз это не отмечено, все остальные настройки — просто мусор/шум? Потрясающе! Большое спасибо за участие в обсуждении.
Теперь я ожидаю, что снятие галочек или сброс всего, кроме Требуется вход, не окажет никакого эффекта. Мне понадобится пара дней, чтобы набраться смелости и попробовать, но я обязательно обновлю эту тему результатами, как только сделаю это.
Discourse v3.5.0.beta3-dev — 
