Discourse ID 작동 방식

[Moin]

도메인 이름을 변경한 후 해야 할 조치에 대한 정보를 첫 번째 게시물에 추가할 수 있을 것 같습니다:

@pmusaraj

Rails 콘솔에 접근할 수 있다면, discourse id 설정의 클라이언트 ID와 시크릿을 비운 다음 Enable Discourse ID 설정을 끄고 다시 켜면 새 등록이 트리거됩니다.

@在云端_裸奔

./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""

[mcwumbly (Dave McClure)]

첫 번째 게시물에 다음 내용을 추가했습니다:

@rishabh

도메인 이름 변경 후 ID 재구성

사이트의 도메인 이름을 변경한 후 새로운 등록을 트리거하려면 다음을 수행해야 합니다.

1. discourse id 설정의 client id와 secret을 비웁니다.
2. Enable Discourse ID 설정을 끄고 다시 켭니다.

Rails 콘솔에 액세스할 수 있는 경우:

./launcher enter app
rails c
SiteSetting.discourse_id_client_id = ""
SiteSetting.discourse_id_client_secret = ""

[Moin]

저라면 레일스 스크립트를 1단계 바로 아래에 넣었을 것 같습니다.

@rishabh

1. discourse id 설정의 client id와 secret을 비웁니다.

이것들은 숨겨진 사이트 설정이므로, 레일스 콘솔을 사용하지 않고는 변경할 방법이 없습니다.

config/site_settings.yml

[0cjs (Curt J. Sampson)]

누군가 이 Discourse ID 인증 제공자(ID provider)를 만든 더 높은 수준의 목표에 대해 알려줄 수 있을까요? 나쁜 점은 전혀 보이지 않지만, 제가 놓치고 있는 좋은 점들이 있는지 확인하고 싶습니다.

GitHub, Google, Apple 또는 Facebook을 사용하는 사용자에게는 Discourse ID를 만드는 것이 아무 이점이 없어 보입니다. 어쨌든 Discourse 사이트에 가입하거나 로그인할 때 “원클릭”(물론 클릭 몇 번)으로 처리되니까요. 그래서 왜 이 옵션이 제공되는 걸까요? 일관성을 위해서인가요?

계정을 GitHub/Google 등과 분리하는 측면에서는 Discourse ID가 합리적인 것 같습니다. 이메일 주소와 비밀번호로 인증하는 경우, 어떤 형태로든 2단계 인증(2FA)을 제공하는 것으로 추측됩니다.

마지막으로, Discourse ID를 다른 비-Discourse 시스템과 함께 사용할 수 있을까요? 기술적으로는 거의 모든 시스템에서 ID 제공자로 사용할 수 있을 것으로 보이지만, 이것이 권장되나요? 비추천되나요? 아니면 언젠가 Discourse ID가 깨질 가능성이 있는 것인가요?

저는 디지털 주권과 "Google/MS 등에서 벗어나고 싶다"는 이유를 모두 포함하여, 누가 인증을 제공하고 왜 제공하는지에 대해 전반적으로 관심이 있습니다. 따라서 대체 인증 제공자에서 일어나고 있는 상황을 이해하는 것은 저에게 매우 흥미로운 주제입니다.

[pmusaraj (Penar Musaraj)]

몇 가지 더 높은 수준의 목표가 있지만, 일반적으로 말하면 두 가지 주요 이점으로 귀결됩니다. 관리자 입장에서는 GitHub, Google, Apple, Facebook 로그인을 설정하고 유지보수할 필요가 없습니다. 각각은 설정과 유지보수가 그렇게 어렵지 않지만, 여러 단계의 설정과 유지보수가 필요하며, Apple의 경우 비용 문제도 있습니다.

최종 사용자의 경우, 현재로서는 큰 차이가 없습니다. 장기적으로 충분히 많은 커뮤니티가 Discourse ID를 채택하게 되면, 사용자가 가입한 커뮤니티에 대한 더 나은 중앙 집중식 인터페이스(ID), 알림 제어, 사용자 계정 사용자 지정 등을 제공하기를 희망합니다. 또한 새로운 커뮤니티를 더 잘 발견할 수 있도록 할 것입니다.