Включен ли автоматический вход для общедоступного сообщества?

Я заметил несколько постов на эту тему, в большинстве из которых говорится, что это функция, доступная только для закрытых сообществ Автологин с плагином OpenId Connect и AWS Cognito — поддержка — Discourse Meta

Как автоматически войти пользователю в веб-виджете приложения — разработка / SSO — Discourse Meta

Мы планируем создать сообщество, где учётная запись предоставляется только в процессе регистрации продукта, но при этом хотим сделать содержимое форума видимым. Это позволит людям, пытающимся найти решение самостоятельно через Google, получать релевантные результаты даже без авторизации (а также поможет нам достичь некоторых целей по SEO для нашего контента).

Возможно ли это или это пустая мечта? Кажется, я не первый, кто задаёт этот вопрос и хочет получить такую возможность.

edit: В частности, я имею в виду этот конкретный аспект спецификации OIDC — Auto-sign-in with the OpenId Connect Plugin and AWS Cognito - #8 by david

Итак, проблема в том, что некоторые пользователи уже вошли в вашу систему Cognito, и вы не хотите, чтобы при попытке ответить им показывалось окно входа? Мне казалось, что при использовании Discourse Connect это поведение по умолчанию.

Вы можете открыть сайт для анонимных пользователей и Google.

В идеальном мире пользователь, просматривающий Discourse и имеющий учётную запись, должен быть авторизован постоянно. Это позволит нам собирать все данные о его просмотрах. Я настрою систему так, чтобы если пользователь продукта перейдёт по ссылке в продукте на страницу сообщества, он будет автоматически авторизован. То же самое касается любых ссылок, которые пользователь должен видеть только при наличии авторизации в другой системе (например, страница учётной записи).

Однако, если пользователь попытается найти решение самостоятельно через Google и попадёт в сообщество, мы не сможем собрать данные о его действиях, пока он не начнёт взаимодействовать с сообществом напрямую, даже если он уже авторизован в других частях нашей системы. Похоже, что единственным способом решить эту проблему является включение настройки сайта login_required, что, если я правильно понимаю, фактически делает сайт приватным.

Спасибо. Я об этом не знал. Я — менеджер сообщества, пытающийся разобраться во всех тонкостях трёх разных продуктов, и это сводит меня с ума, когда приходится вникать в детали каждого из них! Ожидайте от меня ещё несколько постов, пока я пытаюсь во всём разобраться, и спасибо за ваше терпение.

В общем случае это будет невозможно (как определить, есть ли у анонимного пользователя учётная запись, не предложив ему войти?). Однако вполне реально определить, есть ли у пользователя активная сессия на вашем SSO-сайте.

Эта тема довольно старая, но, думаю, принцип всё ещё применим. По сути, добавьте URL с соответствующей поддержкой CORS, который возвращает JSON-ответ, указывающий, есть ли у пользователя активная сессия. Затем добавьте немного JS в вашу тему Discourse, который будет запрашивать этот URL и запускать процесс SSO, если активная сессия обнаружена.

Боюсь, что общий ответ в целом остаётся таким же, как и в прошлый раз.

Речь идёт о спецификации OpenID Connect Session Management. К сожалению, решение на основе iframe становится всё менее полезным, поскольку многие браузеры теперь по умолчанию блокируют сторонние файлы cookie. Теперь оно работает надёжно только в том случае, если ваш провайдер идентификации и Discourse имеют одинаковый «источник» (origin).

Как отметил @simonk, в зависимости от вашего провайдера идентификации возможно реализовать что-то кастомное с помощью компонента темы, но мне неизвестно ни об одном универсальном решении, которое можно было бы добавить в сам Discourse.

Но, кажется, я ошибся.

Вы абсолютно правы: нажатие кнопки «Ответить» запускает процесс входа. Если используется DiscourseConnect (или любой другой провайдер единого входа), то модальное окно входа в Discourse будет пропущено :+1:

Однако, я думаю, что автор темы хочет, чтобы пользователи автоматически входили в систему, без необходимости нажимать «Ответить» или «Войти». При такой настройке переход между основным сайтом и сообществом был бы полностью бесшовным. Мы уже реализовывали это для нескольких клиентов, но это были индивидуальные решения, которые сложно обобщить.

В качестве примера одного из подходов: если ваш форум находится на forum.example.com, а основной сайт — на example.com, то форум может читать куки-файлы с example.com. Таким образом, компонент темы может проверить наличие куки и выполнить что-то вроде этого:

const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
  // У пользователя есть куки-файл авторизации для example.com. Скорее всего,
  // он уже вошёл в систему там, поэтому запускаем процесс авторизации
  window.location = "https://forum.example.com/auth/oidc"
}

(Здесь действуют различные условия. Например, куки не должны быть помечены как http_only, не должны быть куки только для хоста и т.д.)

Действительно, так и есть. Хорошо знать, что это возможно, хотя и требует кастомизации.

Кроме того, поскольку я не знал, что при нажатии кнопки «ответить» диалог входа может быть пропущен в зависимости от реализации, это уже снимает многие мои первоначальные опасения. Это главное препятствие для входа, которого я хочу избежать, и я рад, что его можно обойти.

Конечно, внутренний «человек данных» во мне хочет идеальной версии, и возможно, мы будем стремиться к ней. Но пока достаточно знать, что это возможно. Ещё раз спасибо всем за ваше время.