CODEWITHSUNDEEP
sonarqube
jgxvx
jgxvx

Reputation: 352

Web API: Insufficient Privileges on Private Projects

Configuration Details

We have a SonarQube 6.7.2 (build 37468) on-premise installation running.

The instance is accessible from our office IP without HTTP Basic Auth, as well as from everywhere else with HTTP Basic Auth.

The "Force user authentication" option is off.

All projects are set to private - in case someone gets past the HTTP Basic Auth.

My user belongs to the sonar-administrators groups and has "Browse" and "See Source Code" permissions on all projects.

Using the web interface in the browser, I am able to see all projects including analysis results etc., as expected.

Problem

However, using the Web API, I receive "Insufficient Privileges" errors on several API calls.

My user has a valid token that I pass to cURL as described in the documentation. I even created a new token, to be sure I'm not using an invalid one.

Example

$ curl -X GET -u my_user_token: https://sonar.example.org/api/measures/search_history?component=the_project&metrics=lines_to_cover%2Cuncovered_lines%2Ccoverage&ps=1000
{"errors":[{"msg":"Insufficient privileges"}]}

Question

Is it not possible to retrieve measures information or project information via the API for projects that are set to private?

The above call works fine if the project is to public. (But then again, if the project is set to public, that call works fine even without authentication.)

We do have the same issue when using the SonarLint plugin for PHPStorm. The plugin works fine as long as the projects are public, but server sync stops working as soon as projects are set to private.

I'm thinking maybe it would be best to deny all requests to SonarQube except from our whitelisted office IP and have everyone connect via VPN if they want to access the instance from their home office. That would allow us to make all projects public and not have any of these issues. Is that the recommended way to run an on-premise installation of SonarQube?

Upvotes: 1

Views: 1644

Answers (1)

jgxvx
jgxvx

Reputation: 352

Turns out the SonarQube instance was running behind an nginx reverse proxy that dropped the Authorization HTTP header from the request before passing it on to SonarQube.

After fixing the nginx configuration, all Web API calls work as expected.

Upvotes: 1

Related Questions