안정판 v3.3.3로 재구축 후 SSO 오류 발생

며칠 전에 출시된 최신 안정판인 3.3.3으로 오늘 재구축(rebuild)을 수행한 후 SSO가 작동하지 않게 되었습니다. 현재 로그인된 사용자는 문제없이 사용 중이지만, 새로운 세션에서는 SSO 플로우가 다음과 같은 오류로 종료됩니다:

Account login timed out, please try logging in again.

verbose discourse connect logging을 활성화하면 다음이 표시됩니다.

Verbose SSO log: Nonce is incorrect, was generated in a different browser session, or has expired

그러나 우리의 SSO 플로우에는 지난 수년간 아무런 변경 사항이 없었습니다. 서버 간의 시계도 동기화되어 있습니다.

한편, 우리는 최근에 3.3.2에서 3.3.3으로 업데이트했는데, 이 버전에는 Discourse Connect와 관련된 보안 수정 사항이 포함되어 있어 관련이 있을 수 있습니다.

관련성이 낮을 수 있지만, 재구축은 CDN을 활성화하기 위한 것이었습니다. 하지만 이미 해당 변경 사항을 모두 되돌렸고 SSO 문제는 여전히 남아 있습니다.

이 문제를 추가로 디버깅하는 방법에 대한 조언이 있을까요?

여러 번 재구축한 끝에 v3.3.2로 고정하여 SSO를 다시 작동시킬 수 있었습니다. 따라서 v3.3.3에서 SSO 지원이 깨지는 문제가 도입된 것으로 보입니다.

git diff v3.3.2 v3.3.3을 대충 살펴봤지만 눈에 띄는 내용은 없었지만, Discourse Connect와 관련된 변경 사항이 있습니다.

그러나 3.3.3으로 전환하는 사람들이 많아지고 사용자 세션이 만료되어 갱신이 실패하면서 더 많은 사용자가 이 문제를 겪을 것으로 추정됩니다. 코드, 특히 SSO 플로우에 익숙한 누군가가 더 자세히 살펴볼 가치가 있을 것 같습니다. /cc @sam

P.S. 관련이 있을지 모르겠습니다: 하루 전 3.3.3으로 업데이트했지만, 문제는 몇 시간 전 콘솔을 통해 재구축(CDN을 활성화하기 위해)한 직후에만 발생하는 것 같습니다. (CDN 설정을 되돌려도 SSO 문제는 해결되지 않았습니다.)

3.3.3은 좀 오래되지 않았나요?

네, 대부분의 사용자가 tests-passed 브랜치를 실행한다는 의미에서는 그렇습니다. 하지만 이번 주에 배포된 stable 브랜치의 최신 릴리스라는 의미에서는 아닙니다: 3.3.3: Security and maintenance release

가능성은 낮지만, nonce를 다른 브라우저 세션에서 생성하고 있는 것은 아닌지 확인해 보세요. 예를 들어, 사용자가 브라우저 리다이렉트를 통해 SSO 프로세스를 거치는 대신 애플리케이션의 백엔드에서 SSO 요청을 보내는 경우입니다.

기본적으로 활성화되어 있는 숨겨진 사이트 설정인 discourse_connect_csrf_protection이 있습니다. 사용자의 세션 외부에서 SSO 요청을 허용하려면 이 설정을 비활성화해야 합니다.

해당 설정은 3.3.2 버전에도 존재했을 것으로 추정되지만, 나중에 추가된 것일 수도 있습니다.

그런 경우는 아닙니다. Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) 에 설명된 대로 리다이렉트를 따르는 매우 표준적인 구현 방식을 사용하고 있습니다. 몇 년간 문제없이 작동해 왔으며, 그 부분을 건드리지 않았습니다.

비범한 SSO 처리를 하고 있지는 않지만, 그래도 Rails 콘솔에서 해당 설정을 비활성화해 보았습니다. 그 결과, SSO 제공자가 Discourse로 다시 리다이렉트할 때 Account login timed out, please try logging in again. 오류 대신 아무 메시지도 표시되지 않았습니다(오류든 다른 메시지든). 하지만 불행히도 여전히 로그아웃 상태였습니다.

저 역시도 이 상황이 매우 이상해서 어쩔 줄을 모르고 있습니다. 웹 인터페이스를 통해 3.3.3으로 업데이트했을 때 문제가 나타나지 않았고, 콘솔 재빌드 후 약 36시간이 지나서야 문제가 발생했다는 사실이 단서가 될 수 있다고 생각하지만, 두 방식의 차이점에 대해 충분히 알지 못합니다.

다시 3.3.3으로 업데이트를 시도해 보았지만, 문제는 즉시 재발했습니다. 3.3.2로 되돌리자 SSO가 다시 정상 작동했습니다.

여기서 문제가 DiscourseConnect 보안 수정이 아니라 nginx 변경 사항일 것으로 추정됩니다. tests-passed 브랜치에서는 목요일에 후속 조치가 필요했는데, 일부 환경에서 문제를 일으켰기 때문입니다. 또한 GitHub에서 다른 사용자가 CSRF 문제를 지적하기도 했습니다.

해당 사항에 대한 백포트를 준비해 두었습니다: FIX: Simplify nginx config change (#30383) - Pull Request #30410 - discourse/discourse - GitHub. 머지않아 병합될 것입니다(팀 중 누군가가 승인해야 하는데, 대부분의 팀원에게는 일요일입니다). @mentalstring 님께서는 SSO 설정과 함께 해당 브랜치를 시험해 보셔도 좋습니다.

이 방법이 효과가 있었다는 소식을 전하게 되어 기쁩니다! :tada:

주말에, 게다가 stable과 SSO가 다소 니치한 주제임에도 불구하고 시간을 내어 이 문제를 살펴봐 주셔서 감사합니다. 다른 분들에게도 도움이 되기를 바랍니다. 정말 감사합니다!

PR이 병합되는 것을 지켜보겠습니다.