Passwords and custom user fields left as they are after anonymizing an account?

AI-generated summary

A discussion about the behavior of Discourse’s anonymization feature, specifically regarding passwords and custom user fields. sebix1 observes that anonymizing an account doesn’t delete or anonymize the password and custom fields. Canapin notes that the password hash is changed during anonymization, but custom fields are not removed.

It’s discovered that certain custom fields, such as import_pass and import_id, come from external plugins or import scripts and are not directly related to Discourse. RGJ points out that uninstalling a plugin does not remove its custom fields and suggests that the anonymization procedure should remove all user custom fields.

However, hellekin shares an experience where keeping the password field intact allowed them to reactivate an anonymized account when the user wanted to return. This raises a consideration about the balance between user anonymity and the potential need to restore an account.

Why are the password and custom fields of the anonymized user not deleted/anonymized?

Hello sebix,

I anonymized a user on my test instance. It removed the custom field value, and the password hash was changed, meaning it doesn’t match the previous password.

This is interesting.
I anonymized 1772 users, all of whom kept their import_pass custom fields. Also import_id, but I care less about them.

Using discourse “latest-release +157” (that’s what discourse shows me, I think it’s 0f4beab0fbbd7a163d399e2f94a6aa9cc3dd3ec8), 11 commits behind, but these commits seem to contain no relevant changes.

Regarding the password: You are right, the hash was changed. I didn’t take notice of that. Maybe you can add this information to the first post/the docs?

Thanks for adding these details :slight_smile:

These fields come from Migrated password hashes support.

So it’s not directly related to Discourse. The plugin can be safely uninstalled a while after a migration, when most members have logged in at least once. I don’t know if uninstalling the plugin keeps these fields or not. My guess is it shouldn’t keep them, but if it does, you could empty them from the rails console.

Sure, I’ll do that soon.


Edit: done.

Actually, that plugin reads this custom field. It’s added by most import scripts.

There are no provisions for plugins for any kind of uninstallation logic, so any configuration, database tables or custom fields added by a plugin will stay when the plugin is removed.

By the way, most import scripts also store an import_username custom field.

I think it might be desirable that the anonymization procedure removes all user custom fields, regardless of where they came from. Besides the fact that there is nothing like a registry or ownership for custom fields.

It happened to me that some user wanted out, and they asked to be anonymized. But then they wanted to come back. Having the password field unchanged allowed us to reactivate this account, since we knew who it was.