안녕하세요,
저는 약 3주 동안 Discourse를 사용해 왔으며, 지금까지 그 가능성, 간편함, API, 문서화 및 메타 커뮤니티를 매우 좋아하고 있습니다. 지금까지 정말 훌륭한 경험이었습니다.
저희 회사에는 사용자가 로그인할 수 있는 웹 애플리케이션이 있으며, 이는 사용자 정보를 저장하는 백엔드 시스템과 연결되어 있습니다. 이제 기존 사용자가 SSO를 통해 로그인할 수 있는 Discourse 포럼도 제공하고자 합니다.
저희는 여기에 잘 문서화된 DiscourseConnect를 사용하고 있습니다. 또한 sync_sso 라우트를 사용하여 저희 측에서 만든 변경 사항을 Discourse에 즉시 동기화하고 있습니다. 지금까지 이 방식이 잘 작동하고 있습니다.
현재 프로덕트 오너가 두 가지 요구 사항을 제시했는데, 제가 직접 구현하기 전에 Discourse에서 직접 설정할 수 있는지 확인하고 싶습니다:
-
저희 내부 데이터베이스에는 사용자의 사용자 이름(username)이 없습니다. 하지만 실명(real name) 등은 보유하고 있습니다. 현재 PoC에서는 ssoRecord에 해당 실명을 전송하여 Discourse가 이를 저장하고 사용자 이름을 생성하도록 하고 있습니다. 그러나 법적 이유로 인해 이를 수행할 수 없을 수 있으며, 사용자가 Discourse 인스턴스에 실명을 저장할지, 그리고 어떤 사용자 이름을 사용할지 스스로 결정하도록 해야 할 수도 있습니다.
질문: 사용자가 SSO를 처음 사용할 때를 감지할 수 있으며, 이 경우 사용자가 사용할 이름과 사용자 이름을 선택할 수 있는 일종의 "환영 페이지"로 리다이렉트할 수 있을까요? 이상적으로는 ssoRecord의 값으로 미리 채워져 있어야 하지만, 사용자는 SSO-로그인으로 위장된 등록(SSO-Registration-Disguised-As-Login) 작업을 계속하기 전에 이를 능동적으로 확인해야 합니다. -
확인(confirm)에 대해 말씀드리자면: 다시 말하지만, 사용자가 SSO를 처음 사용할 때, 사용자의 데이터가 실제로 Discourse 데이터베이스에 저장되기 전에 이용약관을 읽고 동의하도록 하는 방법이 있을까요?
이론적으로는 이 두 단계를 저희 웹 애플리케이션 측에서 구현할 수 있습니다. 하지만 다시 한번, 그렇게 하기 전에 Discourse가 기본적으로 제공하는 기능이 있는지 확인하고 싶었습니다. 관리 패널 설정에서 의미 있는 것을 찾지 못해서 여기에서 질문하게 되었습니다 
감사합니다!
수정:
이 유사한 스레드에서 auth skip create confirm 옵션을 사용하라고 제안하고 있지만, 이 옵션은 기본적으로 이미 해제되어 있습니다.