DRAFT: Document iteration of duplicate usernames when user's LDAP email changes
Summary
We do not document how GitLab usernames are iterated upon when a user's LDAP email address changes and introduces a duplicate.
We believe that the behavior matches that of SCIM per @cynthia and @dblessing's research (thanks again!) but this is not documented. Drew states:
We pass the randomized suffix path to uniquify as a counter. So it will only count 4 times. But the curious thing is still that we subsequently pass it unbounded to uniquify again.
🤔 Yeah, we need an issue to test this more.
Steps to reproduce
There is no documentation.
Slack thread: https://gitlab.slack.com/archives/CLM1D8QR0/p1693339656415239
Relevant links for tracking down behavior:
- Using Uniquify: https://gitlab.com/gitlab-org/gitlab/-/blob/684e2489213c3e2ef25942e459de084d0c5ba835/ee/lib/ee/gitlab/scim/base_provisioning_service.rb#L36
-
clean_path
callsRandomlizedSufficPath
which limits to 4 tries: https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/namespace.rb#L251
Example Project
What is the current bug behavior?
What is the expected correct behavior?
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)