此问题随机发生于所有用户。我本人未遇到此问题，但有一次在其他用户遇到此问题时，我曾被登出。我不知道该从何处着手排查。
我在论坛上公开了一个帖子，以提供更多信息。这次有 2 位用户登录成了同一个用户，一位是管理员，另一位不是。他们登录成的用户甚至不是活跃用户。
@Falco 任何关于从何处着手排查的见解都将不胜感激。
@Falco 这个问题已经持续好几年了。据我所知，这是客户端用户会话和 userID 特别是 userID 的问题。如果使用第三方身份验证而不是本地登录（即本地身份验证），则可以规避此问题，但无法修复。
你能确认这是由于你们糟糕的本地身份验证造成的吗？
恕我直言，互联网上有数以万计的 Discourse 安装。仅在我们自己的托管中，我们就运行了数千个，还有许多是自托管的，而您的实例是唯一报告此问题的实例。这意味着您的问题很可能是自找的。
既然您在 Discourse 前面运行了一个自定义反向代理，我建议您先移除它，然后迁移到我们推荐的标准安装设置，再向上游报告此 bug。
3 个赞
我不确定是什么让我的设置是定制的与 discourse 内置的不同，因为它们都是 nginx。不过我不可能将其删除，因为 discourse 不是我托管的唯一内容。我相信这是我的问题，但如果有可能让我发生，也有可能发生在任何人身上。我没有其他关于我托管的软件的问题。我并不是要让你帮我做全部工作，但我找不到其他地方出错了。
如果没有其他线索，或许你知道有人可以帮忙。我已经检查了两个容器以及它们各自的主机上的日志。我不知道还应该从哪里查找出了什么问题。
2 个赞
您认为帖子大小是否会导致此问题？某种溢出/过载的副作用？
我们在多个类别的多个帖子中，回复量会达到数万条。
我可以理解缺乏支持的情况。我们不是付费客户，有些人甚至没有表现得非常友善。我不怪你指责我，因为我也同意，是我在做一些不同的事情导致了这个头痛。如果你真心相信反向代理是造成这个问题的原因，那么这难道不会是一个巨大的安全隐患吗？
我不知道 discourse 的内部工作机制，但对我来说，这似乎是开发者们应该关注的事情。
我们运行的论坛主题回复量远超 70,000，但从未出现过此问题，例如 Forum Jeux vidéo - Gamekult 或 https://forums.woot.com/latest?ascending=false&order=posts
是的，这绝对是一个安全问题。但如果它只在此特定实例上发生，那么这是您网站上的安全问题，而不是 Discourse 上的安全问题，对吗？
我很乐意在此提供帮助。您是否愿意将网站迁移到单独的服务器几周，使用我们的标准安装来排除任何反向代理问题？
1 个赞
如果我的反向代理能够以正确的方式篡改某些令牌或其他东西，使得 Discourse 认为用户变成了别人……那么问题出在反向代理身上真的重要吗？这是否表明其他地方存在可利用之处？
同样，我不知道关于身份验证工作方式的我不知道的事情。
我们因成本增加而放弃了第三方托管，但可能有其他方法可以解决这个问题。我将调查反向代理。目前，我使用此容器是为了便于管理，但我可以尝试其他方法。
我知道您说这只发生在我身上，而且我没有相反的证据，但这真的意味着其他人不可能发生吗？
我将深入研究 Discourse 附带的 nginx 配置，看看是否能理解我哪里做错了。感谢您的见解。
1 个赞
您是否在 Discourse 域下的代理上配置了任何缓存？
1 个赞
我确实使用了提供的缓存选项。这是上述容器附带的配置。
我也使用了“阻止常见漏洞利用”选项。
1 个赞
我不敢说我现在就能理解这里面的任何东西，但当我开始使用 Discourse 时，我在 Discourse 前面使用了 Varnish，并遇到了许多奇怪的问题，比如内容错误。
Discourse 有自己的缓存机制，而反向代理的任何一种缓存方式都可能导致严重的问题。当然，我非常有限的技能与“大牛们”™ 的能力完全不同。
3 个赞
好信息。我可以在这里禁用“附加功能”。
1 个赞
所以你基本上会做Falco已经几次建议过的事情了😏
1 个赞
他希望我完全移除反向代理。这仅仅是移除代理配置中的一些东西。我不知道 Discourse 在内部进行了缓存，这会与外部缓存冲突，所以这是一个有用的建议。
[quote=“Jakke Lehtonen, post:33, topic:328698, username:Jagster”]
所以你基本上会做 Falco 已经建议过几次的事情了
[/quote]他一直垃圾信息链接的就是我们正在做的事情：
这些步骤适用于任何兼容 Docker 的云提供商或本地服务器。
他正在运行标准容器。文档提到使用“兼容 Docker”的盒子，他正在使用。文档甚至提到使用本地服务器，他正在使用。
没有提到使用特殊的批准代理或禁用缓存。
还有配置 SSO 的文档，这似乎在过去引起了与我们现在遇到的类似问题：
仍然没有提到缓存配置或“自定义”反向代理解决方案。
至少，我建议更新文档以突出这些潜在问题，因为它们对 Discourse 专家来说非常明显。
1 个赞
我非常担心这种缓存配置。我不太理解 Nginx 关于 proxy_ignore_headers 的文档，但默认情况下 Nginx 不会缓存 包含 Set-Cookie 标头的响应。看起来该配置正在改变这种行为，使得包含 Set-Cookie 标头的响应可能会被缓存。如果它们被缓存带有 Set-Cookie 标头并提供给另一个用户，这很可能会导致某人切换用户帐户。
理论上，该配置应该只应用于媒体文件，但匹配 URL 的结尾（包括查询参数？）似乎是一种相当不安全的方式来实现这一点。
2 个赞
我已经停止使用它了。因为其他人指出，这似乎总体上是一个相当糟糕的想法。我感谢你的解释。我一开始没有看到它的做法有什么问题，但我显然不是这个领域的专家。
该缓存位置块可能与传递 Cookie 的路由有一些重叠，我们试着禁用它。
1 个赞
我怀疑这是基于@simonk的解释而正确的。
感谢大家的帮助。
我会在一段时间后尝试更新这个，给出一个赞或不同意的意见。如果是这样的话，应该是对其他人有用的警告。