업데이트: 해결 완료!
문제를 해결하기 위해 force_https를 활성화할 수 있었고, 이로 인해 모든 문제가 해결되었습니다. 결국 패스키가 http://로 라우팅을 시도하고 있었지만, 브라우저가 해당 혼합 트래픽을 감지하지 못하고 있었던 것이었습니다. 알고 보니 CloudFlare가 직접적인 원인이 아니었습니다. 이 정보가 앞으로 다른 분들에게 도움이 되길 바랍니다.
원본 게시물:
문제점
안녕하세요! 최근 제 Discourse 인스턴스를 Cloudflare 터널 뒤에 배치했는데, 패스키를 제외하고는 모든 것이 정상적으로 작동하는 것 같습니다. 기존 패스키 등록이든 새 패스키 등록이든 모두 실패하지만, 로그가 실패하는 이유를 명확하게 보여주지 않는 것 같습니다. 여기 계신 분들 중 이 문제를 해결하는 데 필요한 나머지 문제 해결 정보를 찾아줄 수 있는 분이 있을까요?
관련 정보
제 환경에 대해
- Discourse Docker를 사용하여 Discourse를 배포했습니다.
- Postgres와 Redis는 외부에 배포되어 있습니다.
- AWS EC2 인스턴스의 Ubuntu에 배포했습니다.
- 앞서 언급했듯이, Cloudflare 터널이 TLS를 제공하고 프록시로 역할을 하고 있습니다.
시도해 본 것들
- Discourse가 제 포럼 호스트네임(
forums.example.com)을 기대하도록 설정이 올바른지 확인했습니다. - Cloudflare이 TLS를 처리하므로 Discourse를 포트 80 HTTP로 설정했습니다.
- HTTP가 성공하지 못했을 때, 자체 서명된 인증서를 제공하고 HTTPS 프로토콜을 사용하여 포트 443으로 Cloudflare를 Discourse로 리다이렉트함으로써 Discourse가 SSL만 사용하도록 강제하는 것을 시도했습니다.
- Cloudflare이 제 사이트로
forums.example.com을 전달하고 있는지 확인했습니다. 다른 호스트 헤더를 사용하면 Discourse의 NGINX가 404를 반환하기 때문에 이것이 사실임을 알고 있습니다.
관련 로그
- 이 부분은 약간 까다롭습니다. Discourse는 서버 측에서(제가 본 바로는) 아무것도 제공하지 않고 있으며, Bitwarden, iCloud Keychain, Chrome, Firefox 중 어떤 것을 사용하든 결과는 동일합니다.
- 패스키 자체에 대한 로그는 거의 존재하지 않습니다.
- 발견한 가장 유용한 정보는 새 패스키를 생성하려고 할 때 Firefox/Chrome 개발자 도구 콘솔에서 반환된 내용입니다. 다음이 반환됩니다:
{
"errors": [
"The origin of the authentication request does not match the server origin."
]
}
이는 클라이언트와 Discourse(즉, 프록시) 사이에 무언가 잘못되고 있음을 명확하게 나타내지만, 이 로그들은 이 문제를 더 자세히 해결하기 위해 오고 가는 정보가 무엇인지 보여주지 않습니다.
이 문제를 해결하기 위해 확인해야 할 다른 설정이나 로그 위치, 또는 다른 문제 해결 권장 사항이 있을까요? 가능성은 낮지만, Nginx 설정의 실수도 요인이 될 수 있다고 생각합니다. 기본적으로 클라이언트와 Discourse 사이에 CloudFlare와 Nginx가 모두 실행되는 이중 프록시 구조입니다. 이 설정의 일부에 대해 재고해 볼 필요가 있을까요?
우선순위 측면에서는 수정되는 것이 분명히 좋겠지만, 수천 명 중 패스키를 사용하는 사용자는 약 8명뿐이고(다른 로그인 방식은 정상 작동하므로) 크게 스트레스를 받지 않고 있습니다.