현재 로컬 Discourse 설치 환경이 없어서, 얼마나 도움을 드릴 수 있을지 확신할 수 없습니다.
404 응답을 보니, Discourse 사이트에서 Discourse Connect가 실제로 활성화되어 있는지 궁금해집니다:
로컬 angular 앱과 프로덕션 Discourse 사이트를 사용하여 테스트하고 있는 것으로 보입니다. 그래도 동작할 것으로 예상하지만, 이것이 문제를 일으키고 있을 수도 있습니다. 404가 아닌 다른 종류의 응답을 반드시 받아야 합니다.
@simon 답변 감사합니다.
이 부분은 제가 여러 번 직접 확인해 본 내용입니다.
또한 이 Discourse 사이트의 상위 도메인에 호스팅된 프로덕션 테스트 사이트도 있습니다. 프로덕션 플로우를 테스트해 보실 수 있도록 Discourse Connect URL을 "https://domainsite.com/login"으로 업데이트했습니다. Google 제공자로 로그인하여 테스트해 보셔도 됩니다. 인스펙트 콘솔 로그에서 제가 출력한 에러와 응답을 보실 수 있는데, 상태 코드는 404입니다.
현재 저는 POC(개념 증명) 단계만 진행 중이므로, 괜찮으시다면 이메일 주소를 알려주세요. 그러면 제 Discourse 사이트에서 설정을 꼼꼼히 조사할 수 있도록 관리자 권한을 부여해 드리겠습니다. 다시 한번 시간 내어 도와주셔서 정말 감사드립니다.
확신이 안 서는 부분은 sig와 sso뿐인데, 코드를 보면 제가 제대로 하고 있는 건가요?
이 부분 외에는 문제없습니다. api-key는 모두에게 생성하는 것과 시스템에만 생성하는 것 두 가지를 모두 시도해 봤는데, 결과는 동일했습니다. 가능하시다면 Postman이나 Angular 기반의 동작하는 샘플을 제공해 주시겠습니까?
처음에 코드 스크린샷을 볼 때 이 부분을 놓쳤습니다:
mode: 'no-cors'
Angular 앱에는 익숙하지 않지만, 클라이언트에서 Discourse로 인증된 API 요청을 보내려는 것으로 보입니다. Discourse 코드에서 정확히 어디에서 그런 일이 일어나는지는 모르지만, 제 이해로는 클라이언트에서发出的 관리자 API 요청은 Discourse에서 차단됩니다. 이는 클라이언트에 API 키를 노출하지 않고 요청을 수행할 방법이 없기 때문입니다. 이와 관련하여, 지금 바로 API 키를 변경해야 합니다.
알려주셔서 감사합니다.
한 발짝 더 나아간 것 같습니다.
저도 Postman으로 요청을 보내려고 시도하고 있습니다.
Discourse가 프론트엔드에서 API 키를 사용한 호출을 거부했기 때문에, 클라이언트 측의 mode: 'no-cors' 설정이 차단 원인이 된다면, Postman으로 보내는 것이 괜찮을 것 같다는 생각이 드는데, 맞습니까? 하지만 결과는 동일합니다.
Postman이나 심지어 커맨드 라인에서라도 이 작업을 수행하는 것이 좋은 방법입니다. 게시하신 스크린샷을 보면, 요청 본문에 api-username과 api-key가 포함된 것으로 보입니다. 이 매개변수는 요청 헤더에 포함되어야 합니다. 요청 본문에는 sig와 sso 키/값 쌍이 포함되어야 합니다. 도움이 된다면, WP Discourse 플러그인이 이를 처리하는 방식은 다음과 같습니다: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub .
와! 이제 됐네요,
드디어 작동하네요!
@simon 님, 정말 감사합니다.
문제는 님이 지적하신 바로 그거였어요:
본문(body)에는 sso와 sig 키 페어 두 개만 있어야 하고,
api-key와 api-username은 헤더(headers)에 있어야 합니다.
현재 external_id를 사용하지 않는 사이트에서 이 기능을 활성화하면 어떻게 동작할까요? 이메일만으로 사용자를 로그인할 수 있을까요?
더 일반적으로, 페이로드에서 email과 external_id가 필수 두 가지 필드인 점을 고려할 때, 인증 사이트에서 페이로드를 수신하는 디스커스(Discourse) 측에서 이 두 필드가 어떻게 사용되어 로그인할 사용자 계정을 식별하는지 설명해 주실 수 있을까요?
external_id가 연관되어 있지 않은 경우, 이메일을 사용하고 향후 로그인을 위해 해당 이메일에 external_id를 연관시킬까요?email과 external_id가 서로 다른 디스커스 계정에 연관되어 있어 불일치가 발생하는 경우, 어떤 사용자를 로그인할지 결정하기 위해 external_id를 사용할까요, 아니면 email을 사용할까요? 아니면 오류를 발생시킬까요?감사합니다!
주된 질문이 external_id 필드에 관한 것 같습니다. DiscourseConnect 페이로드에 external_id 필드를 설정해야 합니다. 이 필드의 값은 사용자와 연관되며 절대 변경되지 않는 문자열이어야 합니다. 애플리케이션에 사용자 테이블이 있다고 가정합니다. 해당 테이블에서 사용자 항목의 기본 키를 external_id 필드의 값으로 사용하는 것이 좋습니다.
웹사이트에서 DiscourseConnect 인증을 추가하기 전에 사용자가 이미 Discourse 계정을 생성한 경우, 사용자가 DiscourseConnect를 통해 처음 로그인할 때 Discourse는 DiscourseConnect 페이로드에 포함된 이메일 주소를 기반으로 사용자를 찾으려고 합니다. 사용자를 찾은 후, Discourse 데이터베이스에는 DiscourseConnect 페이로드에서 가져온 external_id가 포함된 레코드가 추가됩니다. 사용자가 다음에 로그인할 때는 이메일 주소가 아닌 external_id로 찾게 됩니다. (참고: DiscourseConnect 페이로드의 require_activation 매개변수를 true로 설정한 경우 이 동작은 작동하지 않습니다.)
Discourse는 대부분의 엣지 케이스에 대해 좋은 폴백 메커니즘을 제공합니다. 사용자가 여러 계정을 보유하거나 이메일 주소와 관련된 문제로 인해 오류가 발생할 수 있습니다. 이러한 사례를 처리하는 방법에 대한 세부 사항은 여기에서 확인할 수 있습니다: Debug and fixing common DiscourseConnect issues.
매우 도움이 되었습니다, 감사합니다! 예상했던 대로 모두 정상 작동하는 것 같네요 
수년간 DiscourseConnect를 WordPress를 제공자(provider)로 사용하여 성공적으로 운영해 왔으며, Discourse나 WP 설정은 변경한 적이 없습니다. 그런데 오늘 새로운 동작으로 보이는 현상을 발견했습니다.
로그아웃하면 예전에는 WordPress 로그인 화면으로 이동했습니다.但现在는 Discourse 로그인 화면으로 이동합니다. Discourse 화면에서 로그인하려고 하면 'Unknown Error’가 표시되지만, 문제는 아예 그 화면에 있어서는 안 된다는 것입니다. WP 로그인 화면으로 가야 합니다.
참고로 로컬 로그인은 활성화되어 있습니다(WP를 사용 중인데 왜 활성화되어 있는지 모르겠습니다). 로컬 로그인을 비활성화하고 로그인하려고 하면 사용 가능한 로그인 방법이 없다고 표시됩니다. 따라서 WP 연결을 인식하지 못하는 것 같습니다. 하지만 다시 한번 강조하지만, 양쪽 설정은 변경한 적이 없습니다. Discourse Connect가 활성화되어 있는지, 연결 URL이 올바른지, 시크릿이 양쪽에서 동일한지 확인했습니다.
3.5.0.beta5-dev 버전으로 최신 상태를 유지하고 있습니다. 또한 WP Discourse 플러그인도 최신 버전입니다.
나도 같은 증상이야. 문제를 찾아볼 수 있는지 직접 테스트해 볼 거야.
저희도 DiscourseConnect를 사용 중이며 동일한 문제를 겪고 있습니다.
몇 년 전부터 이 시스템을 운영해 왔고, 그동안 모든 것이 원활하게 작동했습니다. 오늘 3.5.0.beta8-dev [e91024a221] 버전으로 업데이트했습니다.
기본적으로 SSO 시스템에서 Discourse URL로의 콜백 시 https://discourse.domain.ext/login이 추가되고 있으며, @markschmucker 님과 동일한 화면이 표시됩니다.
또한 헤더 로고를 클릭하면 https://discourse.domain.ext/ 로 이동하며, 로그인에는 성공합니다(버튼을 한 번 클릭하면 됩니다).
이전 버전에서는 session controller가 다르게 동작했던 것으로 보입니다. 외부 SSO에서 시작된 호출임을 인지하고 올바르게 처리했던 것 같습니다.
최근 한 달간 @zogstrip 님이 이 오작동과 관련이 있을 수 있는(100% 확신은 못 하겠지만) 몇 가지 변경 사항을 커밋한 것을 확인했습니다.
현재까지 콜백 메서드에 Discourse URL에 /login을 추가하는 워크어라운드를 적용했으며, 모든 것이 정상적으로 작동하는 것 같습니다.
이 코드 부분에 잠재적으로 문제를 일으킬 수 있는 변경 사항에 대한 조언을 담고 있는 문서가 있는지 제가 놓친 부분이 있다면 알려 주십시오.
지원해 주셔서 감사합니다.
@markschmucker, @jimkleiber, @marco.palumbo 님, No login methods when using Discourse Connect only 에서 강조된 것과 동일한 문제를 겪고 계신가요?
그렇다면 “즉시 인증(auth immediately)” 사이트 설정이 활성화되어 있는지 확인하면 됩니다.
저는 "즉시 인증"이 활성화되어 있습니다.
이 부분에 대해 도움을 주셔서 감사합니다 @zogstrip . 불행히도 “즉시 인증”을 활성화하면匿名用户를 위한 “환영” 페이지를 제공할 수 없게 됩니다.
DiscourseConnect SSO를 사용하여 이름이나 avatar_url을 제거하는 것이 불가능한 것 같습니다. 필드를 빈 문자열로 설정해 보았지만(예: avatar_url=이 base64 sso 매개변수에 포함되는 것을 확인했습니다), 코드에서는 빈 필드를 무시하는 것 같습니다.
제 시스템에서는 이름과 프로필 사진이 선택 사항이지만, 현재 작동 방식으로는 한 번 설정된 후에는 삭제할 수 없고 교체만 가능합니다. 제가 무언가를 잘못하고 있는 건가요? (아니라면, 이 문제를 수정할 수 있을까요?)
[수정]: 이미 답을 찾아보았지만, 위에서 질문을 올린 직후 다른 키워드로 검색해 보니 Allow name removal using SSO - #9 by mentalstring 를 찾았습니다. 해당 게시글에 업보팅을 했지만, 큰 기대는 하지 않고 있습니다. 
위에서 @markschmucker, @jimkleiber, @marco.palumbo가 설명한 것과 동일한 로그인 리디렉션 문제를 겪고 있습니다. 이 문제는 몇 주 전에 발견했으며, 5월 중에는 정상적으로 작동했었던 것을 알고 있었습니다. 위에 작성된 내용을 읽은 결과, 이 문제가 5월 이후의 어떤 업데이트에서 Discourse에 도입된 회귀(regression)라는 확신이 생겼습니다. 왜냐하면 우리 모두에게 동시에 문제가 발생했고, 우리는 모두 정상 작동하는 SSO 코드를 가지고 있었으며, 서로 공유하는 SSO 코드가 없기 때문입니다.
이 문제를 해결할 수 있기를 바라며 버그 보고서를 게시했습니다.
3.6.0-beta1에서 리다이렉트 문제가 수정되었습니다.
@markschmucker 와 @marco.palumbo
이 문제는 몇 주 전에 수정되어 v3.6.0.beta1에서 다시 올바르게 작동할 것으로 보입니다.