로컬 개발 전용입니다. 프로덕션 사이트에는 유용하지 않습니다
로컬에서 Discourse 작업을 할 때, 다양한 로그인 방법을 테스트할 수 있는 기능이 유용합니다. 대부분의 경우 실제 인증 과정 자체보다는 Discourse가 다양한 입력에 대해 어떻게 반응하는지 확인하는 것이 중요합니다. 예를 들어 다음과 같은 경우를 생각해 볼 수 있습니다.
- 이메일이 인증되지 않으면 어떻게 되나요?
- 인증 제공자가 이메일 주소를 보내주지 않으면 어떻게 되나요?
- 인증 제공자가 사용자 이름을 보내주지 않으면 어떻게 되나요?
- 이메일은 일치하지만 UID가 일치하지 않으면 어떻게 되나요?
- 외부 인증을 사용할 때 초대(invites)는 어떻게 작동하나요?
- 로그인 화면은 어떤 모습인가요?
- (여기서 끝없이 이어질 수 있지만… 요지는 알겠죠)
지금까지 유일한 실질적인 선택지는 "개발 환경에 실제 Google/Twitter/OAuth2 등의 인증을 설정하는 것"이었습니다. 이는 작동하지만 매우 번거롭고, 다양한 조합을 테스트하기 위해 여러 Google/Twitter 계정을 만들어야 하는 문제가 있습니다.
조금 더 효율적인 방법을 만들었습니다:
이 플러그인을 로컬에 설치하면 가짜 인증 제공자를 사용할 수 있습니다. Discourse의 관점에서는 Google, Twitter, OAuth2, OIDC 등 다른 어떤 제공자와도 동일하게 작동합니다.
로그인 플로우를 시작하면, 원하는 데이터를 직접 입력할 수 있는 화면이 표시됩니다. 제출된 값은 쿠키를 통해 기억되므로 동일한 작업을 쉽게 반복할 수 있습니다. 필드는 Omniauth Auth Hash Schema와 일치합니다.
ManagedAuthenticator 시스템을 사용하므로, 데이터는 user_associated_accounts 테이블에 provider_name이 developmentauth인 상태로 저장됩니다.
DiscourseConnect도 지원합니다! 이를 사용해 보려면 플러그인을 설치하고 enable_discourse_connect 설정을 활성화하면 됩니다. 다음 로그인 시 DiscourseConnect 필드가 모두 사용 준비가 된 상태로 표시됩니다.
Auth 작업을 할 때 다음에 이 플러그인을 사용해 보고, 개선할 점이 있으면 알려주세요 
이 플러그인은有史以來 가장 보안이 취약한 인증 플러그인임을 유의하세요. 따라서 프로덕션 환경에서는 부팅을 거부하며, 작동하려면
DISCOURSE_DEV_ALLOW_ANON_TO_IMPERSONATE환경 변수를1로 설정해야 합니다.
