I’m running the sonar scanner cli v5.0 in a Windows server on the cloud and I need to scan an on-prem application.
I’m trying to configure the sonar scanner client authentication through a DataPower proxy and one of the requirements is to include API key or token as part of the very first http request the sonarscanner sends, /batch/index in this case
GET /batch/index HTTP/1.1
[GET /batch/index HTTP/1.1]
[Severity level: Chat]
Request Method: GET
Request URI: /batch/index
Request Version: HTTP/1.1
[Full request URI: sonarserver:9000/batch/index]
[HTTP request 1/1]
After capturing the http traffic, I can see the API key is actually sent until the GET /api/settings/values.protobuf HTTP/1.1 request
Is there any way to include the API token in the /batch/index request so I can authenticate the sonarscanner client through the proxy?
How is your proxy configured? The scanner will pass the token for all requests that need authenticating, including
/batch/index. Do you have specific configuration in place on your proxy that only forwards certain headers depending on the URL?
I also used a local proxy to capture sonarscanner client http requests for additional validation, I’m sending the API key with the parameter -Dsonar.login , but the key is actually not sent as part of the /batch/index request, any way to include it in the request?
Sorry, I mixed up 2 endpoints. You’re right, we don’t send any tokens for
/batch/index. Right now, there is no way to send the token when querying that endpoint. The only workaround would be to call some other endpoint manually (using cURL, for example), but I’m not sure that would solve your problem; would it?
Yeah, that would not fix the problem as we need the connection to be initiated from the client itself.
So right now the client gets the list of jar files from the server in an unauthenticated way? SonarQube
Do you know any workaround to handle the provision of these files to the client?
/batch/index is a special endpoint that is not protected. It will get a list of JAR files that are required to bootstrap the scanner for your specific version of SonarQube, including any authentication (there will usually only be 1, which we call the “scanner engine”).
Because the authentication is handled by this downloaded-on-the-fly JAR (and not the “scanner” itself), we need the initial request to be unauthenticated. All subsequent requests will be authenticated.
So no, there’s no real workaround for this. It would be a fundamental shift in how we deal with authentication in context of analyzing a project.