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) 또는 숨겨진 설정이 무엇일까요? 표준 설정은 모두 다 확인해 본 것 같습니다.
사전에 아이디어를 주시면 감사하겠습니다!