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?
@Colin This could match my case. In my case, it is actually a grandparent group that matters. The users are in child groups based on skill ad then in grandhilds based on location.
dev-group1-MA
dev-group1-MI
dev-group1-MN
these groups are all children of dev-group1
dev-group2-MA
dev-group2-MI
dev-group2-MN
these groups are all children of dev-group2
etc.
dev-group1 and dev-group2 are both children of dev-group
in GitHub, access to the repos (and hence access to the corresponding SQ projects) is based on membership in “dev-group”.
No one is directly in “dev-group” or dev-group1 or dev-group2
I would need to check the exact group memberships in place the next time the problem arises to confirm. I checked now, and the two users who are most frequently impacted are correctly in dev-group1-MA, dev-group1, and dev-group at the moment.
One note: the way that Jira is written sounds like it is reproducible every time and that part is not true in my case. it is intermittent. mainly it works as expected. if this happened on every login, it would make the feature completely useless.
Maybe it has to do with a case when the user access SQ but was not logged into GitHub already, and it involves a new login “session” to be initiated? Most devs would stay logged in via the browser to GitHub indefinitely.
@Colin when the problem recurred, the user was only in the grand-child group (e.g. dev-group1-MA) and sonar-users
They were not in my-orgname/all-organization-members or dev-group1 or dev-group
After I manually ran a sync, the user was added back to those 3 groups.
AFter I ran the sync, the user was still unable to login and membership in those 3 groups were lost. So, it seems worse than it was in the past when a manual sync would resolve the issue temporarily.
For the next time it happens, can you please ask the user that losts access to logout and then login again to SQ (instead of manually re-launching the sync)? And check that after the login the membership is correct. This would help us narrow down the issue .
I can ask, but in the past, once the user lost access, they cannot get back in by logout/login again. if they could. that would be a viable workaround (albeit annoying to the end user). As things stand, they have to wait for the next sync to correct the groups.
i am not saying i won’t do the test. I am just giving you a heads up about the expected result. The way you phrased your request to me reflected an inaccurate expectation that they will actually be able to access the needed projects with correct permissions. if that was the case, i would not have opened this ticket.
