Discourse ID는 참여하는 Discourse 사이트 전반에서 더 빠른 로그인 경험을 제공하여, 방문하는 각 Discourse 사이트마다 별도의 로그인을 생성할 필요가 없으며, 클릭 한 번으로 모든 참여 Discourse 사이트에 가입할 수 있습니다. 또한 설정이나 구성 없이 소셜 로그인을 지원하여 Discourse 관리자가 간소화된 로그인 경험을 제공할 수 있도록 합니다.
Discourse 사이트에서 "Discourse ID로 로그인"을 보실 때마다, 의미 있는 대화에 참여하는 데 단 몇 초밖에 걸리지 않습니다
왜 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 설정이 활성화되어 있는지 확인하세요.
DiscourseHub 앱에서 Discourse ID를 사용할 수 있나요? DiscourseHub 앱에서 Discourse ID를 활성화한 개별 사이트에 로그인할 수 있습니다 (다른 로그인 방법과 동일하게). 또한 Discourse ID와 DiscourseHub 간의 더 나은 통합을 작업하고 있습니다. 지켜봐 주세요!
문제 해결
Discourse 사이트가 Discourse ID를 사용하려면 https 프로토콜 아래 있어야 하며 인터넷에서 볼 수 있어야 합니다(즉, ID는 인트라넷 사이트에서 활성화할 수 없습니다). 추가 문제 해결을 위해 discourse-id 태그를 확인하거나 해당 태그를 사용하여 올바른 카테고리(예: Contribute > Bug / Support / Contribute > UX)에서 새 주제를 생성하세요.
도메인 이름 변경 후 ID 재구성
사이트의 도메인 이름을 변경한 후, 새 등록을 트리거하려면 다음을 수행해야 합니다.
discourse id 설정의 client id와 secret을 비웁니다. 이들은 숨겨진 사이트 설정이므로 Rails 콘솔을 사용해야 합니다:
./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""
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.
