우리는 자체적인 Discourse Connect 기능 외에도 OIDC가 Discourse에서 공식적으로 지원되기를 원합니다. 이를 통해 표준 및 팀 플랜의 고객들에게 okta와 같은 외부 솔루션에 의존하지 않고 바로 사용할 수 있는 턴키 솔루션을 제공할 수 있希기 때문입니다.
Distrust는 별도의 서비스이므로 해당 방식으로 배포해야 합니다. README 파일에 설명된 대로 컨테이너에서 실행할 수 있습니다. 안전한 운영을 위해 SSL 종단(SSL Termination)을 처리하는 리버스 프록시도 필요합니다. (향후 이 기능을 직접 구현할 수도 있습니다.)
Discourse를 SSO 제공자로 사용하면서 겪고 있는 문제에 대해 전문가의 조언을 구하고 있습니다.
목표: Discourse를 다른 애플리케이션(LibreChat)의 인증을 처리하도록 설정하고 있습니다. 표준 DiscourseConnect 제공자 기능을 사용하며, distrust OIDC 브리지 서비스가 Discourse와 통신하는 클라이언트 역할을 하고 있습니다.
문제: SSO 플로우가 마지막 단계까지 완벽하게 작동합니다. 사용자는 제 애플리케이션에서 Discourse로 올바르게 리다이렉트되며, Discourse 자격 증명으로 성공적으로 로그인할 수 있습니다. 그러나 로그인 후, 제공된 return_sso_url로 돌아가는 대신 제 Discourse 포럼의 홈 페이지(/)로 리다이렉트됩니다.
막힌 부분 (제거된 원인): 이 문제를 해결하기 위해 상당한 시간을 보냈으며, 이것이 단순한 설정 오류가 아님을 확인했습니다. 다음 사항들은 확실히 배제했습니다:
비밀키(Secrets):discourse connect provider secrets가 올바르게 설정되어 있습니다. 프로토콜 없이 일반 도메인(예: auth.my-site.com)을 사용하며, 비밀 키는 제 클라이언트 서비스의 키와 정확히 일치합니다.
SSO 모드:enable discourse connect provider가 체크되어 있는지 확인했으며, 잘못된 “SSO Client” 설정은 비활성화되어 있습니다.
사용자 정책:must_approve_users가 비활성화되어 있는지 확인했으며, 테스트 사용자는 완전히 검증된 이메일을 가진 관리자입니다.
플러그인: 모든 비공식 제3자 플러그인을 비활성화하고 컨테이너를 재구축했지만, 문제는 여전히 지속됩니다.
핵심 증거: 저를 난감하게 만든 두 가지 결정적인 증거가 있습니다:
HAR 파일 분석: HAR 파일로 전체 네트워크 플로우를 캡처했습니다. 로그인용 /session으로의 POST 요청이 성공적임을 보여줍니다. 서버는 즉시 302 Found 리다이렉트로 응답하지만, Location 헤더는 일관되게 /입니다. 이는 Discourse가 의도적으로 SSO 리다이렉트를 중단하고 있음을 증명합니다.
빈 Rails 로그: 로그인 시도를 하면서 컨테이너 내부의 production.log 파일을 테일링(tail)했습니다. 이 과정에서 로그에 아무것도 기록되지 않았습니다. 이는 Discourse가 이를 오류로 인식하지 않는다는 것을 의미하며, 의도적이고 조용한 동작임을 시사합니다.
질문: 로그에 오류가 없는데도 로그인은 성공적이지만 리다이렉트가 잘못되고, return_sso_url을 무시하고 홈 페이지로 리다이렉트하게 만드는 Discourse 내부 정책, 사전 검사(pre-flight check) 또는 숨겨진 설정이 무엇일까요? 표준 설정은 모두 다 확인해 본 것 같습니다.