Over the past months, we've had many contact requests of GitHub users who could not log in to SonarCloud after they changed their username on GitHub.
The problem is partially fixed thanks to
MMF-1161: they can now log in with their new username. The problem is that under the hood, this creates a new SonarCloud user who has nothing to do with the former one. The consequence is that the user loses his permissions, favorites, tokens, ...
Note: if the user simply changed the case of the login (for instance from "Foo" to "foo"), then it's simply impossible to log in again - even with
We should find a way to support these use cases that happen quite often.
As a GitHub user:
- I change my username on GitHub from "foo" to "bar"
- Next time I connect to SonarCloud, I expect to get a warning message (like when the email is stolen from one account to another) saying:
We noticed that you recently renamed your username on [GitHub|Bitbucket|VSTS]. As a consequence, we have updated your SonarCloud login and personal organization accordingly.
Please update the build scripts that might be using your old personal organization key, or any Web Service call that might be referencing your old SonarCloud login.
- Once I have acknowledge this warning, I can see in the Web UI that:
- My username was updated from "foo@github" to "bar@github"
- My personal organization was updated from "foo-github" to "bar-github"
- Obviously, I still see my favorites, my settings, my tokens, my notifications, ... etc.
Important: with MMF, we should make sure that when a GitHub user simply changes the case of her username (e.g. from "foo" to "Foo"), everything works smoothly too.
The Identity Provider API should allow to provide a provider unique ID, which will be stored in the USERS table.
This ID will be used to identify user during authentication (login won't be used anymore).
During authentication, when detecting that the login has been updated, the user will be redirect to a page where we explain to him what will be the consequence of the renaming of the login on his personal organization (This behaviour will looks like what was done for https://jira.sonarsource.com/browse/MMF-1161).
A UUID should be added to the USERS table in order to not use anymore the LOGIN in other tables.
For new users, this column will contain a generated UUID, and for existing users it will be the login, in order to not have to perform a huge DB migration.