Discourse ID обеспечивает более быстрый вход на всех участвующих сайтах Discourse, чтобы вам не приходилось создавать отдельные учётные записи для каждого посещаемого вами сайта Discourse, и вы могли присоединиться к любому участвующему сайту всего одним кликом. Это также позволяет администраторам Discourse предлагать упрощённый процесс входа с поддержкой входа через социальные сети без необходимости настройки или конфигурации.
Всякий раз, когда вы видите кнопку «Войти через Discourse ID» на сайте Discourse, вы в нескольких секундах от значимых и важных разговоров
Зачем использовать Discourse ID?
Создать один раз — использовать везде
Зарегистрируйтесь в Discourse ID один раз и используйте учётную запись во всех участвующих сообществах Discourse.
Больше не нужно запоминать множество имён пользователей и паролей для разных форумов.
Используйте Google, Apple, Facebook, GitHub или свой адрес электронной почты для регистрации в Discourse ID (вскоре появятся дополнительные варианты).
Часто задаваемые вопросы
Какие платформы для входа через социальные сети поддерживаются из коробки? Без какой-либо настройки Discourse ID включает в себя вход через Google, Facebook, Apple и GitHub (вскоре появятся дополнительные варианты).
Это то же самое, что единый вход (SSO)? Да, Discourse ID — это SSO, но специально разработанный для сайтов Discourse.
Владельцы сообществ видят всю мою активность? Нет, ваша активность на одном форуме не видна владельцам других форумов.
Почему Discourse ID не работает на некоторых сайтах? Discourse ID — это новая функция, и некоторые сообщества ещё не подключились к ней. Попросите администратора вашего сообщества включить её (или проверьте позже).
Готовы включить Discourse ID на своём сообществе? Если вы хотите предложить своим участникам бесшовный процесс входа, перейдите в раздел Администрирование → Вход и аутентификация → Discourse ID (/admin/config/login-and-authentication/discourse-id) и включите его. ID доступен везде, включая сайты, размещённые нами, и саморазмещённые сайты. Если у вас возникают проблемы, убедитесь, что включена настройка force_https.
Могу ли я использовать Discourse ID в приложении DiscourseHub? Вы можете войти на отдельные сайты, на которых включён Discourse ID, через приложение DiscourseHub (как и при использовании любого другого метода входа). Мы также работаем над улучшенной интеграцией между Discourse ID и DiscourseHub. Следите за новостями!
Устранение неполадок
Чтобы сайт Discourse мог использовать Discourse ID, он должен работать по протоколу https и быть доступен в интернете (то есть ID нельзя включить для интранет-сайтов). Для дальнейшего устранения неполадок проверьте тег discourse-id или создайте новую тему в соответствующей категории, например, bug / Support / ux, с этим тегом.
Перенастройка ID после смены доменных имён
После смены доменного имени вашего сайта, чтобы инициировать новую регистрацию, необходимо:
Очистить client id и secret для настроек Discourse ID. Это скрытые настройки сайта, поэтому вам нужно использовать консоль Rails:
./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""
Включить/выключить настройку «Включить Discourse ID» в панели администратора.
I like this idea very much. Unifying the login experience is very appreciated! Makes Discourse easier to use and maybe encourage people to ‘sign up’ to more communities.
I have a couple of additional questions regarding Discourse ID:
I assume there is a central server managing credentials which is contacted by each site validating a discourse ID login? Therefore, although each individual website is not aware of other sites being visited, I assume that information is available centrally on the authorisation server? Do you have any plans to use this information, even if anonymised?
Personally, I am happy with email/password (+2FA in some cases), and would not be in a hurry to adopt Discourse ID for my own logins. I also have no interest in reading websites on my phone, so therefore do not want to have the discourse app installed. I hope site operators retain the option to login with username/email and password going forward. For reference, I do not use any of the other offered SSO options either! I have my passwords managed in my own infrastructure, with each password only being used in one location, and stored encrypted when not in use.
I realise that I may represent an edge case, but hopefully people in my position will be considered by admins when looking at sign-on methods going forward.
Yes, Discourse ID itself is a centralized service. Much like other social logins. We have plans to add more features to ID for end users in the near future, but we don’t have details yet on what those features will be.
Yes, all other login methods will remain available, including local accounts.
While I find it good I dont need to support all Social when I accept Discourse ID, I did not yet enable it since I am not sure about what compliance hell I will get into (EU).
And yet you aren’t. You, as an admin, can’t store unnecessary personal data and you must tell what you are storing, why and how long. Such things. With other services you have to tell you are using those and point to theirs privacy policy. The rest is theirs responsibility. Totally same thing than with Google Analytics, Adsense, Amazon S3, email delivering etc.
So, basically what you have to do is tell. It is user’s choise to use or not to use. If Discourse ID or what ever SSO is the only options then you must be more strict, but that isn’t the situation.
But you don’t need to allow Discourse ID if you don’t want to. I enabled it because I was curious, but there won’t be a single user in my forum at the moment who would use it. Perhaps that situation will change when translations works in full speed, but that is different story. But there isn’t basically any EU rules that is your to concern.
Despite the topic title being “How Discourse ID works”, there doesn’t appear to be any details of how it actually works – things like, what is the protocol between the Discourse site and IdP, what identifiers are passed, to what degree activity between sites can be correlated, and so on. I’ll have to know these sorts of things in order to be able to provide accurate guidance to the site admins I advise as to whether this option should be enabled on their sites.
