one of our users had their account compromised. The workflow to mitigate that was far from ideal.
The rails console was needed for:
Force changing the e-mail address
Force changing the password to something random to force a password reset via e-mail
Killing all active sessions
Furthermore, we found that the e-mail change was only visible in the outbound e-mail logs and nowhere else.
The AI spam-detector caught that spam for new accounts, but wasn’t enabled for this trust level and number of posts. Maybe it would be a good idea to include the option to enable the AI spam-detector for changing countries and/or no post in over a year.
Thanks all for the great software over the years, despite minor flaws like this.
Changing the e-mail there sends a prompt for confirmation to the new one, but does not remove the old one immediately.
The deactivate account button may have been right, but it’s not clearly labeled whether that enforces a password reset via e-mail.
I still wasn’t able to find a kill all sessions button and for password change via impersonate in theory works, but it is really messy especially when users have their account set to a language that the admin/moderator doesn’t speak.
If you have plausible reasons that a user’s email is compromised which in turn has resulted in their discourse account being compromised, You can as an administrator change their email and remove the old email.
You can simply mark an account as deactivated which will force a re-verification of email and essentially nuke all existing sessions.
No, I tried that and I could not do that because it generated a confirmation e-mail for the new e-mail address and until that would have been clicked, the old one was still in the database and likely valid.
I opened this as a bug report/feature request on purpose to possibly make it better later, the concrete task is already been done and the user got his account back.
I’m not so sure this is a bug. This is not even an edge case imo. Users being careless about their data or identity is not a common occurrence and there are enough safeguards present. Making this process easier would potentially have more side effects. This is not something people should have to deal with on a daily basis and if situation is critical enough, administrators know their way around mitigation. Maybe the copy could be improved a bit but definitely not in favour of adding more options to the ui.
I recently put in a feature request for more control over user email addresses for admins, which would address this use-case as well:
Yes, not a common event (fortunately). But critical when it (or something similar) occurs, and requires a fast response. Not the time to be learning how to navigate Bash / the rails console or raising a support ticket!
But deactivating account in the interim doesn’t require navigating rails console. In almost 10 years of managing various discourse communities I have yet to come across a situation that would have required rails console (besides migrating communities or performing bulk actions). I appreciate the fact that there may be cases where making changes directly to db would be considered the safer bet to prevent further damage but not sure if adding more options either to user profiles or admin pages makes sense given that both are already very crowded as is.
True - and will stop them in their tracks quite effectively.
I’m also pretty sure that an admin-forced merge of accounts with subsequent deletion of the offending (now non-primary) email address would be effective - and could also be used to force email changes in other situations. But this is very much a workaround.