안녕하세요!
저는 약 5개의 Discourse 서버를 설정해 왔는데, 모두 이상한 동작을 보이고 있습니다. 실제로 버그인지, 아니면 다른 분들도 동일한 경험을 하셨는지 잘 모르겠습니다.
재현 방법
서버 설정은 순조롭게 진행됩니다.
마법사(wizard)를 통한 설정 과정도 문제없으며, 모든 이미지가 업로드되고 예상대로 표시됩니다.
사용자는 가입 링크를 받고 클릭하여 가입을 완료합니다.
(여기서 문제가 시작됩니다) 사용자가 로그인하면 사이트 로고가 모두 깨져 있으며 텍스트 제목만 표시됩니다.
사용자는 사용자 지정 아바타를 업로드하거나 지정할 수 없습니다.
사이트 인증서가 사이트가 안전하지 않다고 경고합니다.
어째서인지 이 문제는 가입에 사용된 브라우저에만 영향을 미치며, Chrome에서 실패율이 훨씬 높습니다.
문제 해결 시도
사용자에게 브라우저 캐시와 쿠키를 삭제하라고 요청했습니다 – 여전히 깨져 있습니다.
사용자에게 브라우저를 다시 설치하라고 요청했습니다 (대부분 Chrome) – 여전히 깨져 있습니다.
Chrome에서 다른 ID를 사용하거나 다른 브라우저(Safari, Firefox 등)를 사용해 보라고 요청했습니다 – 정상 작동합니다!
마지막 항목이 왜 작동하는지, 그리고 가입에 사용된 ID가 왜 문제를 일으키는지 전혀 알 수 없습니다. 만약 그것이 정말 해결책이라면, 우리 사용자(약 600~700명)에게 Chrome ID에서 로그아웃했다가 다시 로그인하도록 요구하는 것은 지속 가능하지 않을 것입니다.
어떤 아이디어가 있으신가요?
감사합니다,
Mark
표준적인 30분 설치가 맞나요? 아니면 커스텀 작업이 필요한 건가요?
사이트 설정에서 force_https를 활성화해 봤나요? 그러면 문제가 해결될 수 있는지 확인해 보세요.
최신 브랜치의 샌드박스 환경에서 해당 단계를 재현할 수 없으니, 영향을 받는 인스턴스 중 하나에 대한 링크를 공유해 주시면 큰 도움이 될 것입니다.
force_https를 활성화해 보세요. 이 방법으로 문제가 해결될 가능성이 99%라고 확신합니다.
알겠습니다. 모든 설치 인스턴스는 동일한 머신이 아닌 리버스 Nginx 프록시에서 인증서를 받습니다. 이 경우 force_https 설정이 여전히 차이를 만들 수 있을까요?
그러니까 표준 설치 방식은 아닌 거네요. 처음에는 그렇지 않다고 하셨는데.
Discourse가 적절하게 구성된 리버스 프록시 뒤에 있다면, force_https 설정은 확실히 차이를 만듭니다. 이 설정은 기본적으로 Discourse가 모든 리소스와 에셋을 HTTPS를 통해 로드하도록 지시합니다.
아, 죄송합니다.
그럼, app.yml의 force_https를 말씀하시는 건가요, 아니면 Nginx 서버 블록을 말씀하시는 건가요?
이미 트래픽을 제대로 전달하고 있는데, yml 파일에서 해당 프로퍼티를 찾지 못하겠습니다.
그 어느 쪽도 아닙니다.
force_https는 관리자 영역에서 활성화해야 하는 사이트 설정입니다.
리버스 프록시가 잘못 설정된 경우를 제외하고는, 이 부분에 대해 전혀 걱정할 필요가 없습니다.
리버스 프록시 설정에 대해 확실하지 않다면, 이 설정을 참고하여 자신의 설정과 비교해 보세요.
This guide is intended for advanced users, who are already using nginx outside the docker container. By following this guide you make your setup more complicated and will lose some speed benefits like HTTP2 if you’re not running Ubuntu 16.04 or later. Proceed with caution!
When Discourse is rebuilding or starting up, your users will usually either see an error message from their browser…
[image]
…or a not-so-nice 502 error message from Nginx:
[image]
If you’re a perfectionist …
참고로 실제로 그랬어요. 로그인이 차단됐거든요. force_https를 활성화하니 이미지 문제는 해결됐지만, 새 세션으로 브라우저에서 인증하는 것이 불가능해졌어요. 기존 세션은 문제없었지만, 로그아웃하는 순간 다시 로그인할 수 없었어요.
리버스 프록시에 문제가 있는 것 같습니다. 모든 것이 올바르게 설정되어 있는지 확인하려면 구성을 점검해야 합니다.
방금 해봤는데, 해당 글에서 제안한 대로 서버 블록에 이미 모든 설정을 효과적으로 해놓은 상태입니다. 아마도 이것이 최초 가입/인증 이후 대체 프로필/브라우저에서 세션이 정상적으로 작동하는 이유일 것입니다.
제 설정에서 다른 유일한 부분은 templates.yml을 사용하지 않는다는 점입니다.
이 문제를 해결하려면 훨씬 더 많은 조사가 필요할 것 같습니다.
음. 이상하네. 아무것도 변경하지 않았는데, 모든 이미지가 완벽하게 정상적으로 작동해. 끝.
그래도 최초 설치 시 브라우저/사용자 환경에서만 여전히 잘못된 인증서 오류가 발생해.
브라우저 캐시 문제이거나 인증서 설정 오류일 수 있습니다. Let’s Encrypt SSL을 사용했나요, 아니면 다른 인증서를 사용했나요?
Certbot를 통한 LetsEncrypt입니다. 인증서는 정상입니다. 브라우저 캐시 문제라고 생각합니다.
시크릿 모드에서 등록을 시도해 보세요. 그래도 오류가 발생하나요?
그리고 여기 하나 의심스러운 부분이 있습니다. 외부 인증을 사용 중이신가요? (소셜 로그인 / SSO 등)
아니요. 외부 인증도 아닙니다. 시크릿 모드로도 시도해 봤는데, 역시 마찬가지입니다. 같은 결과가 나오네요.
서버 블록에 뭔가 문제가 있는 것 같습니다. 조금 후에 자세히 조사해 보겠습니다.
riking
(Kane York)
5월 22, 2020, 4:27오후
20
여기에 나열된 설정을 기준으로 nginx 설정을 작성하셨나요?
If you want to run other websites on the same machine as Discourse, you need to set up an extra NGINX or HAProxy proxy in front of the Docker container.
NOTE: This is for advanced admins
This guide assumes you already have Discourse working - if you don’t, it may be hard to tell whether or not the configuration is working.
You cannot use ./discourse-setup to set up Discourse if another server is using port 80 or 443. You will need to copy and edit samples/standalone.yml with your favorite tex…
X-Forwarded-Proto 헤더를 보내고 있는지 확인하세요.