이 문제는 모든 사용자에게 무작위로 발생하고 있습니다. 제 계정에서는 아직 일어나지 않았지만, 다른 사용자에게 이 문제가 발생했을 때 제가 한 번 로그아웃된 적이 있습니다. 어디서부터 시작해야 할지 전혀 감이 잡히지 않습니다.
더 많은 정보를 제공하기 위해 제 포럼에 관련 스레드를 공개적으로 개설해 두었습니다. 이번에는 두 명의 사용자가 동일한 계정으로 로그인되었는데, 그중 한 명은 관리자 권한이 있었고 다른 한 명은 없었습니다. 로그인된 해당 사용자는 현재 비활성 상태입니다.
https://forum.pixelspace.xyz/t/user-substitution-issue-tracking/1429
@Falco 어디서부터 살펴봐야 할지 조언을 주시면 감사하겠습니다.
@Falco 이 문제는 수년째 지속되고 있습니다. 제가 아는 한, 이 문제는 클라이언트 측 사용자 세션과 특히 userID와 관련된 문제입니다. 로컬 로그인(즉, 로컬 인증) 대신 서드파티 인증을 사용하면 이 문제를 우회할 수는 있지만, 근본적으로 해결되지는 않습니다.
이것이 귀하의 부실한 로컬 인증 시스템 때문이라는 것을 확인해 주시겠습니까?
존중하는 마음으로 말씀드리지만, 인터넷에는 수천 개의 Discourse 설치 환경이 있습니다. 저희 호스팅 서비스만 해도 수천 개를 운영 중이며, 자체 호스팅하는 곳도 많지만, 이 문제를 보고하는 곳은 여러분의 인스턴스뿐입니다. 이는 여러분의 문제가 가장 가능성 높은 자체 유발 문제임을 의미합니다.
Discourse 앞에 커스텀 리버스 프록시를 실행 중이시므로, 여기에서 버그를 보고하기 전에 이 프록시를 제거하고 저희가 권장하는 표준 설치 환경으로 전환하는 것부터 시작하시길 권합니다.
제 환경이 커스텀 설정인지, 아니면 Discourse에 기본적으로 포함된 것인지 확신이 서지 않습니다. 둘 다 nginx를 사용하거든요. 다만 Discourse를 제외한 다른 서비스도 호스팅하고 있어서 nginx를 제거하는 것은 불가능합니다. 제 문제인 것 같지만, 제게 이런 일이 생길 수 있다면 다른 사용자들에게도 생길 수 있는 일입니다. 제가 호스팅 중인 다른 소프트웨어에서는 문제가 없습니다. 손을 잡아달라는 것은 아니지만, 다른 부분에서는 아무런 문제가 발견되지 않습니다.
어디를 봐야 할지 다른 통찰을 주실 수 없다면, 혹시 도움을 줄 수 있는 분을 아시는지 궁금합니다. 두 컨테이너와 각각의 호스트 로그를 확인해 봤습니다. 무엇이 잘못되었는지 더 어디를 봐야 할지 모르겠습니다.
스레드 크기가 이 문제를 일으키고 있다고 생각하시나요? 오버플로우/오버런의 부수적인 효과 같은 것일까요?
우리는 여러 카테고리의 여러 스레드에서 수만 개의 답변을 주고받고 있습니다.
지원이 부족한 이유를 이해합니다. 우리는 유료 고객이 아니며, 일부 사용자는 매너가 매우 나쁜 편이기도 합니다. 제가 문제를 일으키는 다른 요인이 있다는 지적에 동의하므로, 당신을 탓하지 않습니다. 다만, 역프록시(revers proxy)가 이 문제의 원인이라고 진심으로 생각하신다면, 이는 심각한 보안 문제가 되지 않나요?
디스코urs의 내부 구조에 대해 제가 모르는 것이 무엇인지 모르지만, 제 생각에는 개발팀이 관심을 가져야 할 사항으로 보입니다.
우리는 70,000개 이상의 답변을 가진 주제들이 있는 포럼을 운영하고 있으며, Forum Jeux vidéo - Gamekult 또는 https://forums.woot.com/latest?ascending=false&order=posts 와 같은 곳에서 이러한 문제가 발생하지 않았습니다.
네, 분명히 보안 문제입니다. 하지만 이것이 이 특정 인스턴스에서만 발생한다면, 이는 Discourse의 문제가 아니라 여러분의 사이트의 보안 문제인 것이죠, 맞나요?
저는 여기서 도움을 드리고 싶습니다. 리버스 프록시 문제를 배제하기 위해, 표준 설치 방식으로 사이트를 별도의 서버로 이동하여 몇 주간 운영해 보실 의향이 있으신가요?
역프록시(revers proxy)가 어떤 토큰이나 유사한 것을 적절한 방식으로 변조하여 Discourse가 사용자가 다른 사람으로 변경된 것으로 인식하게 만든다면… 그 문제가 역프록시에 있는지 여부가 정말로 중요할까요? 이는 다른 곳에서 악용될 수 있는 취약점을 나타내는 것이 아닐까요?
다시 말하지만, 인증이 어떻게 작동하는지에 대해 제가 모르는 부분이 많다는 것을 알지 못합니다.
비용 증가로 인해 3자 호스팅에서 벗어나게 되었지만, 그 문제를 해결할 다른 방법이 있을 수도 있습니다. 역프록시를 조사해 보겠습니다. 현재는 관리의 편의를 위해 이 컨테이너를 사용하고 있지만, 다른 것을 시도해 볼 수도 있습니다.
그것이 저에게만 발생한다고 말씀하시지만, 반대의 증거는 없습니다. 하지만 이것이 다른 누구에게도 불가능하다는 것을 의미하는 건 아니지 않나요?
Discourse가 기본적으로 제공하는 nginx 설정을 살펴보고, 제가 어디서 잘못하고 있는지 이해할 수 있는지 알아보겠습니다. 조언해 주셔서 감사합니다.
Discourse 도메인의 프록시에서 캐싱이 구성되어 있나요?
제가 제공된 캐싱 옵션을 사용 중입니다. 이는 위에서 언급한 컨테이너에 포함된 설정입니다.
또한 ‘공통 익스플로잇 차단’ 옵션도 사용하고 있습니다.
지금 당장 여기서 무슨 일이 일어나는지를 이해한다고 주장하지는 않겠지만, Discourse를 처음 사용했을 때 Varnish를 Discourse 앞에 배치했는데, 잘못된 콘텐츠가 표시되는 등 여러 가지 이상한 현상을 경험했습니다.
Discourse는 자체 캐싱을 수행하므로, 리버스 프록시를 통한任何形式的 캐싱은 사실상 큰 문제입니다. 하지만 제 제한적인 기술은 ‘빅 Guys™’가 할 수 있는 것과 매우 다른 것이죠.
좋은 정보네요. 여기서 '추가 기능’을 비활성화할 수 있겠네요.
결국 당신은 이미 몇 번이나 제안했던 팔코의 말을 따르는 거겠죠 
그는 리버스 프록시를 완전히 제거하라고 했습니다. 이건 단순히 프록시 설정에서 몇 가지를 제거하는 것입니다. discourse가 외부 캐싱과 충돌할 수 있는 내부 캐싱을 수행하고 있다는 사실을 몰랐으니, 유용한 제안이었습니다.
그가 계속 스팸으로 올리는 링크는 우리가 이미 하고 있는 내용입니다:
이 단계는 모든 Docker 호환 클라우드 제공업체 또는 로컬 서버에서 작동합니다.
그는 표준 컨테이너를 실행하고 있습니다. 문서에는 “Docker 호환” 박스를 사용하라고 언급되어 있으며, 그는 이를 사용하고 있습니다. 문서에는 로컬 서버를 사용하라고도 언급되어 있으며, 그는 이를 사용하고 있습니다.
특수 승인된 프록시를 사용하거나 캐싱을 비활성화해야 한다는 언급은 없습니다.
또한 SSO 구성에 대한 문서도 있으며, 과거에 우리가 경험한 것과 유사한 문제를 일으킨 것 같습니다:
여전히 캐싱 구성이나 “사용자 정의” 리버스 프록시 솔루션에 대한 언급은 없습니다.
최소한으로, 이러한 잠재적인 문제들이 Discourse 전문가들에게는 너무도 명백하므로 문서를 업데이트하여 이를 강조하는 것이 좋습니다.
해당 캐싱 구성에 대해 매우 우려스럽습니다. proxy_ignore_headers에 대한 nginx 문서를 완전히 이해하지는 못했지만, 기본적으로 nginx는 Set-Cookie 헤더가 포함된 응답을 캐시하지 않습니다. 해당 구성은 Set-Cookie 헤더가 포함된 응답이 캐시될 수 있도록 이 기본 동작을 변경하는 것으로 보입니다. 만약 이러한 응답이 Set-Cookie 헤더와 함께 캐시되었다가 다른 사용자에게 전달된다면, 이는 사용자의 계정이 전환되는 문제를 일으킬 수 있습니다.
이론적으로는 해당 구성이 미디어 파일에만 적용되어야 하지만, URL의 끝부분(쿼리 파라미터 포함)을 일치시키는 방식은 이를 구현하는 상당히 위험한 방법처럼 보입니다.
더 이상 사용하지 않고 있습니다. 다른 분들이 지적하듯, 전반적으로 꽤 나쁜 아이디어인 것 같습니다. 설명해 주셔서 감사합니다. 처음에는 그 동작에 대해 아무런 문제가 보이지 않았지만, 저는 해당 분야 전문가가 아니므로 확신할 수 없습니다.
해당 캐시 위치 블록은 쿠키를 전달하는 라우트와 일부 중복될 수 있으니, 비활성화를 시도해 보겠습니다.
@simonk 님의 설명을 근거로 볼 때, 이것이 맞을 것 같습니다.
모든 분들의 도움에 감사드립니다.
조금 후 이 내용을 업데이트해서 찬성인지 반대인지 알려드리겠습니다. 그렇게 된다면 다른 분들에게도 유용한 경고가 될 것입니다.