-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
When a user is deactivated, his SSO data is not deleted #11072
Comments
I think deactivating a user clears their password---sounds reasonable that other login-related information is reset too. Is this about removing redundant data, or is it possible to log in with the SSO mapping even if you've been deactivated? |
I'm not sure I agree that this should be removed. If it was removed than the user would likely be able to login as a new user. By keeping the SSO mapping we ensure that the SSO identity is mapped to the same user (internally). |
Isn't that data that has to be deleted according to the GDPR? |
The SSO ID must be a unique, immutable identifier to be valid. Using something that the user can change is a configuration error (one which Synapse could not detect, it full depends on your setup). Most SSO providers have some sort of incrementing ID or GUID you should use here.
I'm not sure I understand what you're saying here. I'm picturing the following:
Is this the same chain of events you're thinking of? I suppose the reason for the deactivation is important here -- if the user is deactivated in order to ban them you would not want them to be able to log back in using the SSO identity; if the user is deactivated just to delete their account than creating another account in the future might make sense. |
I think this is covered by the So, we could just remove the SSO mapping if |
Related: note that Synapse's implementation of the C-S API includes undocumented support for the |
Note that this issue relates to the extremely verbose gitter.im usernames for those of us who ever used gitter.im before it was all Matrix: I will have to live with being |
I have the same issue - an old verbose username when I first connected GitHub to gitter years ago. |
I also attempted deactivation to get rid of the junk in my username, but I also cannot log in or create a new account with GitHub, currently the only provider that directly uses the username. Is this eventually going to be possible? |
Description:
I cannot find a call to delete user's SSO mapping when user is deactivated.
synapse/synapse/handlers/deactivate_account.py
Line 54 in 4044442
IMO it should be deleted.
In addition there needs a background job to clear old SSO mappings for deactivated users.
The text was updated successfully, but these errors were encountered: