This continues to occur randomly to any and all users. It hasnt happened to me but I did get signed out when it happened to someone else once. I have no idea where to even begin looking.
I have a thread going on my forum that I made public to provide more information. This time 2 users became logged in as the same user, one an admin, one not. The user they became isnt even active.
@Falco Any insight as to where to look is appreciated.
@Falco this is an ongoing issue for several years now. As far as I know this is an issue with the client side user session and the userID specifically. This issue is only circumvented but not fixed if instead of the local login aka local auth the third party auth is used.
Can you confirm that this is caused due to your subpar local auth?
With all due respect, there are many thousands of Discourse installs out there in the internet. Just in our hosting we run thousands, and there are many self-hosting too, and your instance is the only one reporting this issue. This means that your issue is most likely self-inflicted.
Since you are running a custom reverse proxy in front of Discourse, I’d start removing this and moving to our blessed standard install setup before reporting the bug upstream here.
I’m not certain what makes my setup custom vs whats baked into discourse as they’re both nginx. Its not possible for me to remove it though as discourse is not the only thing I’m hosting. I’m sure its my problem, but if its possible to have happen for me its also possible to have happen for anyone. I have no other issues with any of the software I’m hosting. I’m not asking for you to hold my hand here but I cant find anything wrong otherwise.
If there is no other insight you might be able to give as to where to look, perhaps you might know someone who can. I’ve tried checking logs on both containers as well as their respective hosts. I’m not sure where else to look for what gone wrong.
Do you think thread size could be causing this? Some sort of side effect of an overflow/overrun?
We go into the tens of thousands of replies on multiple threads, in varying categories.
I can understand the lack of support. We arent paying customers and some of us arent even being very nice. I dont blame you for pointing the finger at me as I agree, its something I’m doing different that causes this headache. If you genuinely believe the reverse proxy is whats causing this issue though, would this not be a huge security issue?
I dont know what I dont know about the inner workings of discourse but to me this seems like something that should be of interest to the devs.
We run forums where topics go way over 70k replies and this haven’t caused this issue, like Forum Jeux vidéo - Gamekult or Woot
Yes, it is definitely a security issue. But if it only happens on this specific instance it is a security issue on your site, and not on Discourse, right?
I’d be happy to help here. Would you be open to move the site to a separate server for a couple of weeks using our standard install to rule out any reverse proxy issues ?
If my reverse proxy is able to mangle some token or whatever in the right way such that discourse believes a user has become someone else… does it really matter if the issue lies in the reverse proxy? Would this not indicate something exploitable elsewhere?
Again not knowing what I dont know about how the auth works.
We moved away from 3rd party hosting due to increased costs but there may be another way we can tackle that. I will investigate the reverse proxy. Currently I use this container for ease of administration however I could try something different.
I know you’re saying it only happens for me, and I have no proof to the contrary, but does it really mean its not possible for anyone else?
I will do some digging on the nginx config discourse ships with to see if I can understand where I’m doing something wrong. I appreciate your insight.
Do you have any caching configured on the proxy under the Discourse domain?
I do use the caching option provided. This is the config that ships with that container above.
I also use the ‘block common exploits’ option.
I don’t claim I would understand anything here and now, but when I started using Discourse I had Varnish front of Discourse, and I exprienced a lot of funny things, as wrong content.
Discourse is doing its own caching and practically any kind of caching by a reverse proxy is big time serie bad ideas. But sure, my very limited skills are very much different thing than what Big Guys™ can do.
good info. I can disable the ‘additional features’ here.
So you will basically do what Falco has suggested already couple times now 
He wanted me to remove the reverse proxy entirely. This is simply removing some things from the proxy config. I didnt know discourse was doing caching internally that would conflict with external caching so thats a useful suggestion.
The link he keeps spamming is what we’re already doing:
these steps will work on any Docker-compatible cloud provider or local server.
He is running the standard container. The docs mention using a “Docker compatible” box, which he is using. The docs even mention using a local server, which he’s using.
There is no mention of using a special approved proxy or disabling caching.
There is also docs for configuring SSO, which seems to have caused similar issues to what we’re experiencing in the past:
Still no mention of caching configuration or “custom” reverse proxy solutions.
At minimum I would suggest updating the documentation to highlight these potential issues, since they’re so obvious to Discourse experts.
I’d be very nervous of that caching configuration. I don’t fully understand the nginx docs for proxy_ignore_headers, but by default nginx will not cache responses that include a Set-Cookie header. It looks like that config is changing that behaviour so that responses including a Set-Cookie header might be cached. If they are cached with the Set-Cookie header and then served to a different user, that might well cause someone to switch user accounts.
In theory that configuration should only apply to media files, but matching the tail end of a URL (including query parameters?) seems like a fairly unsafe way to do that.
I have discontinued its use. Since others have pointed to that it seems like a pretty bad idea overall. I appreciate the explanation. I didnt immediately see anything wrong with what it was doing but I’m certainly not subject matter expert.
That cache location block may have some overlap with routes that deliver cookies, let’s try disabling it.
I suspect this is correct based on the explanation @simonk gave.
I appreciate everyones help.
I’ll try to update this in a while to give a yay or nay. It should be a useful warning to others if so.