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.
각 사이트가 Discourse ID 로그인을 검증할 때 자격 증명을 관리하는 중앙 서버에 접속한다고 가정하고 있습니다. 따라서 각 개별 웹사이트는 다른 사이트 방문 여부를 알지 못하지만, 해당 정보가 인증 서버에서 중앙 집중식으로 이용 가능하다고 추정합니다. 이 정보를 익명화하더라도 활용하실 계획이 있으신가요?
개인적으로는 이메일/비밀번호(+ 경우에 따라 2FA)를 선호하며, 제 자신의 로그인에 Discourse ID를 도입할 조급함은 없습니다. 또한 스마트폰으로 웹사이트를 읽을 관심이 없으므로 Discourse 앱을 설치할 의향도 없습니다. 앞으로 사이트 운영자가 사용자 이름/이메일과 비밀번호로 로그인하는 옵션을 유지해 주기를 바랍니다. 참고로, 제가 제안된 다른 SSO 옵션도 전혀 사용하지 않습니다. 제 비밀번호는 제 자체 인프라에서 관리되며, 각 비밀번호는 한 곳에서만 사용되고 사용되지 않을 때는 암호화되어 저장됩니다.
제가 특수한 사례일 수 있다는 점을 인지하고 있지만, 제와 같은 상황에 있는 사람들이 앞으로의 로그인 방식 검토 시 관리자들에 의해 고려되기를 바랍니다.
그런데 당신은 아직 그렇지 않습니다. 관리자로서 불필요한 개인 데이터를 저장할 수 없으며, 무엇을, 왜, 얼마나 오래 저장하는지 알려야 합니다. 그런 것들이죠. 다른 서비스를 사용하는 경우, 해당 서비스를 사용한다는 사실을 명시하고 그 서비스의 개인정보 처리방침을 참조하도록 해야 합니다. 나머지는 그 서비스의 책임입니다. Google Analytics, AdSense, Amazon S3, 이메일 전달 서비스 등에서도 완전히 같은 원리입니다.
결국 해야 할 일은 알려주는 것입니다. 사용할지 말지는 사용자의 선택입니다. Discourse ID나 기타 SSO가 유일한 옵션이라면 더 엄격해야 하지만, 현재 상황은 그렇지 않습니다.
원하지 않는다면 Discourse ID를 허용할 필요가 없습니다. 저는 호기심에 활성화했지만, 현재 제 포럼에서 이를 사용할 사용자는 단 한 명도 없을 것입니다. 번역이 완전히 정상 작동하기 시작하면 상황이 바뀔 수도 있지만, 그것은 별개의 이야기입니다. 기본적으로 당신이 신경 쓸 유럽연합(EU) 규칙은 없습니다.
제목이 “Discourse ID의 작동 방식”이지만, 실제로 어떻게 작동하는지에 대한 세부 사항은 보이지 않습니다. 예를 들어, Discourse 사이트와 IdP 간의 프로토콜은 무엇인지, 어떤 식별자가 전달되는지, 사이트 간 활동이 어느 정도까지 상관관계로 추적할 수 있는지 등입니다. 제가 조언하는 사이트 관리자들과 이 옵션을 해당 사이트에 활성화해야 하는지 여부를 정확히 안내하려면 이러한 정보들이 필요합니다.
