Inconsistent authorization for some users

we are testing a new installation of SonarQube Developer 9.7.1 where users are authenticated with the AAD plugin (GitHub - hkamel/sonar-auth-aad: Azure Active Directory Authentication for SonarQube) and the authorization is managed with AAD-synched groups.

It happens for most users to see projects in the main (Projects) page, that they are not authorized to see, while they don’t see projects that they should see (they are in a group where the “Browse” permission is granted). On the SonarQube main page they see “2 of 25 shown” project, when we have only 5 projects in this instance: they were more but most projects have been deleted one day ago.

Still on the main page the users have a “Show more” button next to “2 of 25 shown” footer, but if they click it nothing happens.

The same can happen for the admins, who can not see all projects in the main page, but they can see them all on the “Administration > Projects > Management” page. The same happens for AAD-synched admin user and for the local admin user.

Additionally some new users have logged in (we allow the sign-up for AAD users), but the admins can not see them in the “Administration > Security > Users” page.

So far we were using another instance which runs SonarQube Community 9.7.1, where we never noticed this issue so far: there we have 165 projects, which are visible by the admins both in the main page and in the “Administration > Projects > Management” page.

Both the Community and the Developer instances are running on AKS Kubernetes (version 1.23.12) clusters and SonarQube is installed via the official Helm chart (version 5.0.6+370) and both instances are running with 2 replicas. At first we thought that the 2 replicas could be the problem, but the Community instance runs on 2 replicas without the same issues.

A difference between the 2 instances is that on the Developer one we have configured GitHub as DevOps platform integration, while on the Community instance we did not set up any DevOps platform integration; anyway I don’t think that it could be related to our issue.

Has somebody experienced similar issues? Thanks in advance.

Hey there.

This tells me something isn’t right with the Elasticsearch index of your SonarQube instance. Typically, we would suggest deleting the data/es7 folder on your instance and restarting the SonarQube service (so that a reindex occurs).

You can only have a single SonarQube instance connected to a database – multiple instances connected to one server can cause problems just like these (because if a project is deleted, only one instance will find out about this and alter the index). Node redundancy is only supported in Data Center Edition.

Hey Colin,

thanks for your helpful message: I have created a new replica set with just one replica and now all previously reported issues are gone.

I guess that we will have to live with a single instance from now on.

1 Like