I am experiencing this issue in 10.7 but it has been occuring for quite a while, it is not new to 10.7 or other recent release (I would guess this has been ongoing for roughly 9 months).
SonarQube ID information
Version: 10.7.0.96327
Date: 2024-10-29
Deployed as a zip file
We have configured GitHub as the authentication provider and automatic group and user provisioning. In general, it meets our needs very well. However, for some reason, for some users, the automatic group sync does not include all of the groups (specifically does not include membership in sonar-users so the users cannot log in).
Workaround 1: Wait long enough and the situation resolves itself
Workaround 2: Go into the UI and manually “Synchronize now”
I cannot detect any patterns for when the sync will be incomplete. It seems to only impact some users, but I can’t say that 100% for sure, perhaps other users are just not reporting it and are waiting for the issue to resolve itself on it’s own. It has never happened to my account. So far, workaround 2 has resolved the issue every time but it doesn’t seem logical to me that it would behave differently than the scheduled sync. As a rough estimate, I have probably done workaround 2 around a dozen times.
FYI, User “S” in the screen shots above complained about this issue at 12:37 PM US/Eastern
I did my manual sync of the groups at 12:42 PM US/Eastern
Below is the contents of web,log around that time
2024.10.29 10:34:44 INFO web[][c.s.p.c.ProvisioningTaskCreator] Scheduled GITHUB_AUTH_PROVISIONING provisioning task: 567bf58e-8c66-4733-a7b2-f3be56212317.
2024.10.29 11:36:20 INFO web[][o.a.t.u.h.Parameters] Invalid chunk starting at byte [0] and ending at byte [40] with a value of [=PHPE9568F36-D428-11d2-A769-00AA001ACF42] ignored\n Note: further occurrences of Parameter errors will be logged at DEBUG level.
2024.10.29 11:39:44 INFO web[][c.s.p.c.ProvisioningTaskCreator] Scheduled GITHUB_AUTH_PROVISIONING provisioning task: 7a7b2344-d52b-4ee6-a6a8-ba724ed0f879.
2024.10.29 12:42:28 INFO web[3d42a922-ca67-4dd6-bd80-37fabe8cab7b][c.s.p.c.ProvisioningTaskCreator] Scheduled GITHUB_AUTH_PROVISIONING provisioning task: 7127bc79-be43-482c-a1c2-d3d3f3668f8c.
2024.10.29 13:44:46 INFO web[][c.s.p.c.ProvisioningTaskCreator] Scheduled GITHUB_AUTH_PROVISIONING provisioning task: 0b686c4e-3e74-4613-94d4-2d7140bc41bb.
Can you please turn on DEBUG level on both your web and CE logs, to see if there any kind of erroneous scenario, and share it here ? Without this we won’t be able to help.
I finally got a chance to capture the logs. If there is a private place these can be uploaded, let me know. However, i don’t think you will need the full logs, i created a word doc that captures the key pieces of info IMO. On login, sq is checking the users groups and removing any “parent” github groups. I will attach a word doc that contains extracts of the relevant info. Hopefully this helps to troubleshoot. Most likely, we have an unusual setup which is why others are not seeing the same issue.
sonarqube_web.log showing the login failure for the impacted user (random-github-user123)
2024.11.25 10:05:57 DEBUG web[bad5dc01-3212-4f78-baee-158eccb7798c][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|127.0.0.1|192.168.42.114][login|]
2024.11.25 10:05:58 DEBUG web[][o.s.s.p.s.p.PushEventPollScheduler] Received 0 push events, attempting to broadcast to 6 registered clients.
2024.11.25 10:05:59 DEBUG web[6858aa9a-7c0d-428a-99f6-1defc193f784][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|127.0.0.1|192.168.42.114][login|]
2024.11.25 10:05:59 DEBUG web[7ea4853c-0b52-4504-a2e1-8d4dd633641b][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|127.0.0.1|192.168.42.114][login|]
2024.11.25 10:05:59 DEBUG web[59783da1-8e3c-46b5-986a-1dbb196fb5b6][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|127.0.0.1|192.168.42.114][login|]
2024.11.25 10:06:02 DEBUG web[c2e2bccd-80ab-4f24-a9b3-0f367731d61a][o.s.s.a.UserRegistrarImpl] List of groups returned by the identity provider '[sunbirddcim/dct-web-nj]'
2024.11.25 10:06:02 DEBUG web[c2e2bccd-80ab-4f24-a9b3-0f367731d61a][o.s.s.a.UserRegistrarImpl] Removing group 'sunbirddcim//all-organization-members' from user 'random-github-user123
2024.11.25 10:06:02 DEBUG web[c2e2bccd-80ab-4f24-a9b3-0f367731d61a][o.s.s.a.UserRegistrarImpl] Removing group 'sunbirddcim/dctrack' from user 'random-github-user123
2024.11.25 10:06:02 DEBUG web[c2e2bccd-80ab-4f24-a9b3-0f367731d61a][o.s.s.a.UserRegistrarImpl] Removing group 'sunbirddcim/dct-web' from user 'random-github-user123
2024.11.25 10:06:02 DEBUG web[c2e2bccd-80ab-4f24-a9b3-0f367731d61a][auth.event] login success [method|OAUTH2][provider|EXTERNAL|GitHub][IP|127.0.0.1|192.168.42.114][login|random-github-user123]
During the synchronization, members of the child team are added to the parent team and the child team in SonarQube
When the user logs in, he is then kicked out of the parent team.
Do you think this could be what’s going on?
I could envision a scenario where the sync is done (groups are right), the user logs in (groups are wrong), the sync is done (groups are right again) that might mimic the behavior you see.
Is there a parent/child relationship between the groups that your user stays in, and the groups your users are yoinked from?
