단순히 proxy_set_header X-Forwarded-Proto https;만 사용하면 될까요?
http/s 요청은 컨테이너에서 인터넷상의 Discourse ID용 IDP 서버로 전송됩니다. 요청 헤더를 추가하거나 변경할 수 있는 중간 인스턴스가 없습니다.
개인적인 의견으로는 “Discourse ID”가 표준 OAuth라고 가정할 때, 올바른 방법은 다음과 같습니다.
a) Discourse ID에 “well-known” 구성 엔드포인트를 추가할 수 있는 구성 옵션을 제공하는 것입니다. 이 엔드포인트에는 “https://… 접두사를 포함한 필요한 모든 OIDC 구성 값이 포함되어야 합니다.
b) 동일한 내용을 코드에 이미 하드코딩해 두는 것입니다.
여전히 Discourse ID의 기술적 세부 사항에 대해 고민하고 있습니다 …
Discourse ID의 세부 사항은 우리의 코드에서 확인하실 수 있으며, 우리가 사용하는 프로토콜은 모두 GitHub 저장소에 있습니다. 다른 OAuth 구현 방식과 유일한 차이는 인스턴스를 자동 등록한다는 점입니다. 그리고 이 자동 등록 과정에서, 등록을 요청하는 인스턴스가 스스로 주장하는 대로 실제로 해당 인스턴스인지, 그리고 https를 사용하고 있는지(http://를 사용하는 Discourse 인스턴스는 이 시대에 존재해서는 안 됩니다) 확인합니다.
위에서 공유한 http 오류는 여러분의 사이트가 올바르게 설정되어 있지 않음을 나타냅니다.
콘솔을 통해 다음 명령어의 출력을 확인해 보실 수 있을까요?
Discourse.base_url
SiteSetting.force_https
첫 번째 명령에서 http:// URL이 반환되고 두 번째 명령에서 false가 반환된다면, SiteSetting.force_https = true로 설정하여 문제가 해결되는지 확인해 보시는 것이 좋습니다. (다만, 다른 부분의 설정이 잘못되어 있다면 이 설정이 오히려 문제를 일으킬 수도 있으니 주의하세요.)
Penar님,
먼저 제 설정에 대한 세부 사항을 명확히 해야 할 것 같습니다. 표준 배포 방식과는 약간 차이가 있습니다.
- 중앙 로드 밸런서(https://www.haproxy.org/)가 여러 웹 서비스(단순히 Discourse뿐만이 아닙니다)의 SSL 가속기로 역할을 수행합니다. 인터넷에서 이러한 서비스 중 어느 하나로도 HTTPS를 통해서만 접근이 가능합니다. HTTP에서 HTTPS로의 전환은 로드 밸런서 자체에서 수행되며, 참고 자료로 https://www.haproxy.com/blog/redirect-http-to-https-with-haproxy를 확인해 주세요.
- haproxy는 프론트엔드 요청을 암호화 없이 비공개 네트워크(10.x.x.x)의 백엔드로 전달합니다. 이 트래픽은 도커 호스트의 로컬 nginx에서 종료됩니다.
- nginx는 요청을 web_only 컨테이너의 HTTP 소켓으로 전달합니다.
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(web_only.yml과 data.yml을 사용하는 2컨테이너 구성을 사용하고 있습니다. 참고 자료로 templates/web.socketed.template.yml을 확인해 주세요)
모든 HTTPS 암호화가 컨테이너 외부에서 수행되므로 SiteSetting.force_https는 필요하지 않습니다. 이미 Discourse OpenID Connect (OIDC) 플러그인을 기반으로 자체 IDP를 사용하여 OAuth를 적용하고 있습니다. Discourse OIDC 플러그인에는 “well-known” OpenID Connect discovery document 설정이 포함되어 있습니다. 제 경우: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
만약 Discourse ID가 Discourse 컨테이너 인스턴스와 Discourse ID IDP 간의 링크에 대해 유사한 기능을 구현한다면 문제가 되지 않을 것입니다. "Discourse ID"가 고정된 IDP를 사용하므로, HTTPS 접두사를 포함하여 이러한 "well-known URL"을 하드코딩할 수도 있습니다.
Thomas, 죄송하지만 당신의 특정 설정에 대해서는 제대로 도움을 드리기 어렵습니다. 말씀드릴 수 있는 것은 당신의 인스턴스에서 무언가 잘못된 상태라는 점뿐입니다.
음, 당신의 사이트 JS 콘솔은 컨테이너 외부에서 이루어지는 https 암호화가 모든 것을 커버하고 있다고 생각하지 않는 것 같습니다. 위에서 공유한 그 JS 경고들은 당신이 겪고 있는 문제의 증상으로, 당신의 설정에서 Discourse 자체는 http으로 실행되고 있다고 인식하고 있으며, 이는 일부 경우에 http URL을 생성하게 되므로 문제가 됩니다.
Penar, 정말 정말 죄송합니다:
저희 프로덕션 인스턴스(PROD)의 설정과 DEV 인스턴스의 설정을 비교해 보았습니다. force_https 설정을 비활성화한 곳은 DEV 인스턴스뿐이었습니다. 그리고 이는 DEV 인스턴스 앞에 SSL haproxy SSL 가속기가 배치되어 있었기 때문에 가능했던 것입니다.
이제 DEV 인스턴스에서 SiteSetting.force_http를 활성화했고, Discourse ID가 정상적으로 작동합니다. 따라서 저희 프로덕션 인스턴스(forum.netzwissen.de)에도 Discourse ID를 배포할 예정입니다.
혼동을 드려 죄송합니다.
걱정 마세요, 해결되어서 다행이에요. 후속 조치해 주셔서 감사합니다!