Hey crew ~ I’m getting caught up after taking the day off yesterday.
I adjusted the sensitivity of the “hiding a post due to a flag” feature from medium to low. We can also disable it. I agree. I think it’s sure nice to have for spam, but I don’t want it hiding posts when folks just disagree or think someone is being “rude” or something along those lines. We can also fully disable that feature, which I’m happy to do down the line if it becomes a problem.
I have a, what I think/hope, is a very positive update on the alarming “wrong log-in” glitch that had affected a few (which is too many) users. I’m going to provide the info from the developers below, then sort of translate it a bit for anyone who is interested in a condensed version:
In addition to Discourse’s own user session and cookie, we’ve added a couple of persistent cookies that will keep the user information. Think of it as a current user state. Whenever Discourse incorrectly changes a user session, we’ll compare it with the user state we have in our cookies. On detecting a different user state knowing that the user hasn’t logged in with a different user or logged out. We’ll automatically log out the user and create a log in DB.
This way, it will record any session mix up that will occur on the site and automatically logout the user if it detects an incorrect/mixed up session.
On your 7 am, when there were 35 active users on the site. We did a mass logout on the site for safety measures. So every user will now have to re-validate their accounts on the site.
Can I assure them if they log out, that no-one else can inadvertently log into their account, if they choose to steer clear of the site until we get it sorted out?
Yes, you can assure them of that. Also, this issue is server and Discourse related. There are no malicious user hacking or impersonating attempts on the site. Discourse software needs services on server which handle user requests and queue them up for processing. Our current server stack is a combination of Discourse, Apache/Passenger, Redis, and PostgreSQL. There seems to be some issue between the communication of Discourse and Passenger and as a result there is a mix up of user requests between them. We’re continuously trying more ways of fixing it.
We think our new user impersonation prevention and automatic logout system will temporarily resolve user concerns while we are looking into setting up and deploying a different server stack (Docker) for Discourse for a permanent fix.
To summarize, they’ve set up a system to automatically detect any of these log-in mixups and automatically logout the person from the wrong account (and make a log of it so they know if it’s happened.) That’s a short-term fix, so if there’s a mistake, it’ll be fixed right away automatically.
Long-term, they are changing the server stack system they use in conjunction with Discourse to avoid these mixups permanently.
And, I can assure you that if you’re still not comfortable for the time being, you can choose to not visit for a bit and you don’t have to worry about anyone being mistakenly logged into your account (though this should now be resolved). These problems only happened between users that had log-in requests queued up in the system, and they were getting mixed up by the server.
Please know that we take this issue very seriously at all levels.
Thank you!