저희 포럼의 호스팅 관리 업무를 인수받았는데, 이전에 Discourse Connect로 설정되어 있는 것 같습니다. 이 설정을 이해하지 못하고, 찾을 수 있는 문서를 읽어봐도 아직까지 명확한 이해에 이르지 못했습니다.
이것이 단순히 남아있는(vestigial) 설정인지(그렇다면 정리하고 싶습니다), 아니면 포럼이 DiscourseConnect 인증의 클라이언트이자 서버인 것처럼 동작하고 있는지는 불분명합니다. 더 잘 이해할 때까지는 접근 권한을 잃고 싶지 않아서 아무것도 변경하는 것이 두렵습니다. DiscourseConnect에 대한 게시물에는 단일 로그인(Single Sign On)에서 전환되는 방법에 대한 다음 내용이 포함되어 있습니다.
제가 올바르게 이해하고 있다면, DiscourseConnect를 비활성화하면 모든 사용자에게 비밀번호 재설정을 요구하게 되는 건가요?
컨텍스트를 제공하기 위해 제가 공유하기에 안전하다고 생각하는 설정 내용을 최대한 공유하겠습니다. 아마도 DiscourseConnect가 인증 플로우의 프로바이더(Provider)이자 클라이언트(Client)로 동시에 설정되어 있는 것 같고, 이것이 저를 혼란스럽게 하고 있습니다.
게시글을 작성한 후, 추천된 글들에서 2019년에 올라온 이 Disable DiscourseConnect 게시물을 발견했습니다. 명확한 절차가 있어서 도움이 되지만, 현재 시스템이 어떻게 작동하는지에 대한 기본적인 이해는 여전히 부족합니다.
로그인이 리디렉션되지 않는다고 상당히 확신합니다. 로그인 페이지는 실제로 Discourse 특유의 자산, data-exporters, 스크립트 등이 가득한 바닐라 Discourse 로그인 플로우처럼 보이며, 우리가 실행 중인 포럼의 특정 커밋으로 연결되는 콘솔 링크까지 있습니다.
이로 인해 Discourse가 인증에 대한 자체적인 단일 정보 원본(source of truth) 역할을 하고 있다는 확신이 생겼습니다.
제가 정확히 이해하지 못하는 부분은, DiscourseConnect 설정이 외부 사이트에서 이메일, 사용자 이름 등을 오버라이드하도록 되어 있으면서도 /session/sso_provider 엔드포인트도 활성화되어 있는 이유와 방식입니다. …이는 Discourse가 동시에 로그인에 대한 책임을 포기하면서 단일 정보 원본 역할도 하고 있는 것과 같은 것 아닌가요? 아니면 DiscourseConnect의 SSO가 어떻게 작동하는지에 대한 핵심적인 이해나 문서가 부족한 것일까요?
Discourse v3.5.0.beta3-dev — 
