Я пытаюсь более чётко разобраться в возможных вариантах решения задачи по реорганизации проекта, над которым работаю. Я искал информацию на форумах, чтобы получить дополнительные insights, и хотя нашёл похожий вопрос, сценарий автора оригинального поста немного отличается от нашего, поэтому я создаю эту новую тему.
В настоящее время у нас есть сайт на WordPress по адресу domain.com, настроенный как клиент SSO для экземпляра Discourse по адресу community.domain.com. Однако сайт WordPress планируется реорганизовать в сеть мультисайтов, например, sub1.newdomain.com, sub2.newdomain.com и т. д., с отдельным экземпляром Discourse для каждого сайта, например, forum.sub1.newdomain.com (или, в идеале, sub1.newdomain.com/forum, если нам удастся настроить работу через подпапку).
Мы хотим, чтобы у наших пользователей была единая идентичность во всех сообществах, и мы знаем, как синхронизировать пользователей, регистрирующихся на одном подсайте WordPress, по всей сети. Я понимаю, что один экземпляр Discourse может выступать в роли сервера SSO для другого, но не смог найти подтверждение того, как это настраивается и работает ли это для нескольких клиентов Discourse.
Итак, мои вопросы:
В описанном сценарии возможно ли настроить экземпляр Discourse, например, по адресу auth.newdomain.com, чтобы он выступал одновременно как сервер SSO для сети WPMS и для всех экземпляров Discourse, связанных с подсайтами?
Если ответ на предыдущий вопрос положительный, целесообразно ли настроить этот экземпляр «сервера» так, чтобы он предоставлял только функции аутентификации? То есть, чтобы он служил исключительно «источником истины» для аутентификации во всей сети, независимо от того, к какому сайту пользователь обращается для входа. Или в этом случае более уместно использовать внешнее решение для аутентификации?
Привет — это сообщение появилось у меня, так как вы сослались на мою оригинальную тему. Я дам возможность @simon поделиться своим мнением, но один из вариантов, который может сработать (или нет), и который был бы гораздо проще, — это развернуть один экземпляр Discourse и использовать группы для разделения форумов. Информацию о группах можно передавать в полезной нагрузке SSO.Однако настройка нескольких форумов, где только один выступает в роли провайдера SSO, должна быть довольно простой (хотя я сам это раньше не пробовал). Я полагаю, шаги будут следующими:
Установите плагин WP Discourse и настройте его как клиент SSO (в настройках сети).
Настройте форум Discourse, который должен работать как провайдер SSO (добавьте секретные ключи в WP и Discourse и т. д.).
Далее, при добавлении последующих форумов их нужно будет настроить как клиентов SSO (и поскольку WP Discourse настроен на уровне сети, вам не придется менять какие-либо конфигурации при добавлении новых сайтов).
Огромное спасибо за ваши предложения, @jakeols. Я понимаю, что группы часто предлагают в качестве альтернативы, но они не подходят для нашего конкретного случая.
Надеюсь, @simон сможет пролить свет на то, что здесь возможно, а что нет.
Вы можете использовать Discourse в качестве провайдера SSO для сети мультисайтов. Это работает только в том случае, если вы настроили один сайт Discourse как провайдера SSO для всех сайтов в сети. Причина в том, что в мультисайтовой сети все пользователи хранятся в одной таблице базы данных. Если разрешить нескольким сайтам Discourse функционировать как провайдерам SSO для разных сайтов в сети, не будет простого способа гарантировать уникальность идентификаторов пользователей Discourse, сохраняемых в WordPress.
При установке плагина WP Discourse в мультисайтовой сети в меню администратора сети появляется вкладка Discourse. Чтобы настроить Discourse как провайдера SSO для всех сайтов в сети, перейдите на страницу администратора сети, выберите в меню пункт Discourse. Выберите опцию «Включить конфигурацию мультисайта», затем заполните настройки подключения. Далее прокрутите страницу вниз до раздела настроек SSO. Выберите опцию «Включить SSO-клиент». Введите ваш секретный ключ SSO и сохраните страницу настроек.
Одно важное замечание: включение функциональности SSO-клиента в мультисайтовой сети потенциально может предоставить доступ любого пользователя вашего форума Discourse к любому сайту в вашей сети.
По сути, если вы пытаетесь реализовать что-то отличное от описанного выше с использованием Discourse в качестве провайдера SSO для мультисайтовой сети WordPress, вам придётся решать задачу самостоятельно. Технически возможно разрешить нескольким сайтам Discourse функционировать как провайдерам SSO для отдельных сайтов в сети WordPress, но требуемая для этого конфигурация была бы излишне сложной. Я не думаю, что эта функция когда-либо будет добавлена в плагин для WordPress.
Огромное спасибо за ваш ответ. Цитируемое вами сообщение — это именно то, на что я ссылался в своем первоначальном посте. У меня нет особых проблем со стороны WordPress — мы знаем, как подключиться на сетевом уровне и затем синхронизировать пользователей на всех подсайтах. Меня больше интересует, как настроить один Discourse в качестве сервера SSO для другого? Я пытался уточнить, возможно ли это, когда Discourse, отвечающий за аутентификацию, одновременно является сервером SSO и для WordPress.
Мне не удалось найти документацию по схеме взаимодействия Discourse с Discourse. Если вы сможете указать, где найти дополнительную информацию, или просто описать необходимые шаги, я буду крайне признателен.
Я понимаю вашу точку зрения, но Discourse не предназначен для использования исключительно в целях аутентификации. Я бы посоветовал вам уделить время рассмотрению вопроса о выделенной службе аутентификации, которую вы сможете подключить к своим различным экземплярам Discourse и WordPress. Немного инвестиций в исследования сейчас могут окупиться в будущем.
Однако мой главный совет вам заключается в следующем: то, что вы предлагаете, является сложным, и независимо от выбранного пути вам необходимо настроить тестовую среду, которая зеркально отражает вашу планирующуюся производственную среду, чтобы экспериментировать с различными конфигурациями перед запуском. Такая настройка может зависеть от множества различных переменных, и трудно дать советы по этому поводу в абстрактной форме.
Я понимаю, что идея создания полностью отдельной тестовой среды для взаимосвязанной сети серверов может показаться трудоемкой, но трудозатраты на это намного меньше, чем попытки решить непредвиденные проблемы, которые возникнут после запуска подобной системы.
Да, я признаю, что Discourse не является чистым сервисом аутентификации. Мы рассматриваем три возможных варианта:
Использование Discourse в качестве нашего провайдера идентификации
Использование WordPress в качестве нашего провайдера идентификации
Использование внешнего провайдера идентификации (SaaS или самописного)
Каждый из этих вариантов имеет разные последствия для затрат, сложности и пользовательского опыта, которые мы хотим оценить, поэтому я задаю здесь эти вопросы.
Нет, ты абсолютно прав, это действительно сложно, и мы даже не подумаем о развертывании этого без предварительного тестирования в тестовой среде. Большое спасибо за объяснение, очень ценю!
