Authentication Failure in SonarScanner for .NET with Valid Token and Project Key on SonarQube 2025.1

SonarQube Server / Community Build
, ,
1

Hi,

I’m encountering an authentication issue with SonarScanner for .NET when analysing a project on our SonarQube server (version 2025.1.1.104738). Despite using a valid global analysis token and a resolvable project key, the scanner fails with an authentication error and attempts to access the API using component=unknown.

Environment Details

SonarQube Server Version: 2025.1.1.104738
SonarScanner for .NET Versions Tested: 10.4.1 and 10.3.0
Operating System: Windows 10
Token Type: Global Analysis Token (sqa_…) and also user token (squ_…).
Token Validation: Successful for both tokens via /api/authentication/validate
Project Validation: Successful via /api/settings/values?component=<my_project>

Reproduction Steps

Run the scanner with the following command:

dotnet sonarscanner begin /k:"<my_project>" /n:"<my_project>" /d:sonar.host.url=<valid_url> /d:sonar.login="<sqa_valid_token>" /d:sonar.verbose=true

The verbose scanner output includes:

Downloading from <valid_url>/api/settings/values?component=unknown…
Response received from <valid_url>/api/settings/values?component=unknown…
WARNING: Authentication with the server has failed.
Pre-processing failed. Exit code: 1

Troubleshooting Performed

  • Verified token validity (for both tokens) via /api/authentication/validate.
  • Verified project key via /api/settings/values?component=<my_project>
  • Confirmed that I can scan projects with other .NET scanner (SonarScanner.MSBuild.exe) using the same Global Analysis Token.
  • Downgraded scanner to 10.3.0 — issue persists.
  • Uninstalled and reinstalled scanner v.10.4.1 — issue persists.
  • Attempted scan using manually downloaded DLL — same result.
  • Switched off “Force user authentication” in UI — issue persists.
  • Tried /d:sonar.scanner.useSonarScannerCLI=true — no effect.
  • Tried /d:sonar.token=“<sqa_valid_token>” instead of /d:sonar.login=“<sqa_valid_token>” — no effect.
  • Ran from a clean directory — no change.
  • No conflicting environment variables or config files.

Request

Could you please advise if this is a known issue or regression? Is there a workaround or patch available to resolve the component=unknown error and allow successful authentication?

I can provide verbose logs or additional diagnostics upon request.

1 Like
2

Hi,

Welcome to the community!

Could you provide that full log, please?

 
Thx,
Ann

3

Hi Ann,

I assume you want the scanner verbose output. Here it is…

SonarScanner for .NET 10.4.1
Using the .NET Core version of the Scanner for .NET
Default properties file was found at C:\Users\<reducted>\.dotnet\tools\.store\dotnet-sonarscanner\10.4.1\dotnet-sonarscanner\10.4.1\tools\netcoreapp3.1\any\SonarQube.Analysis.xml
Loading analysis properties from C:\Users\<reducted>\.dotnet\tools\.store\dotnet-sonarscanner\10.4.1\dotnet-sonarscanner\10.4.1\tools\netcoreapp3.1\any\SonarQube.Analysis.xml
sonar.verbose=true was specified - setting the log verbosity to 'Debug'
Pre-processing started.
Preparing working directories...
Using environment variables to determine the download directory...
08:09:14.346  Loading analysis properties from C:\Users\<reducted>\.dotnet\tools\.store\dotnet-sonarscanner\10.4.1\dotnet-sonarscanner\10.4.1\tools\netcoreapp3.1\any\SonarQube.Analysis.xml
08:09:14.428  Server Url: <reducted>
08:09:14.428  Api Url: <reducted>/api/v2
08:09:14.428  Is SonarCloud: False
08:09:14.439  No truststore provided; attempting to use the default location.
08:09:14.442  No truststore found at the default location; proceeding without a truststore.
08:09:14.446  sonar.verbose=true was specified - setting the log verbosity to 'Debug'
08:09:14.46  Updating build integration targets...
08:09:14.469  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\4.0\Microsoft.Common.targets\ImportBefore
08:09:14.471  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\10.0\Microsoft.Common.targets\ImportBefore
08:09:14.473  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\11.0\Microsoft.Common.targets\ImportBefore
08:09:14.478  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\12.0\Microsoft.Common.targets\ImportBefore
08:09:14.48  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\14.0\Microsoft.Common.targets\ImportBefore
08:09:14.482  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\15.0\Microsoft.Common.targets\ImportBefore
08:09:14.484  The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\<reducted>\AppData\Local\Microsoft\MSBuild\Current\Microsoft.Common.targets\ImportBefore
08:09:14.489  Installed SonarQube.Integration.targets to <reducted>\src\.sonarqube\bin\targets
08:09:14.493  Creating config and output folders...
08:09:14.495  Creating directory: <reducted>\src\.sonarqube\conf
08:09:14.497  Creating directory: <reducted>\src\.sonarqube\out
08:09:14.523  Downloading from <reducted>/api/settings/values?component=unknown...
08:09:14.653  Response received from <reducted>/api/settings/values?component=unknown...
08:09:14.657  WARNING: Authentication with the server has failed.
08:09:14.658  WARNING: In version 7 of the scanner, the default value for the sonar.host.url changed from "http://localhost:9000" to "https://sonarcloud.io".
If the intention was to connect to the local SonarQube instance, please add the parameter: /d:sonar.host.url="http://localhost:9000"
08:09:14.663  Pre-processing failed. Exit code: 1

Please note that the problem is quite recent. I was regularly using the scanner 2 week ago without issues. Also, the file C:\Users\\.dotnet\tools\.store\dotnet-sonarscanner\10.4.1\dotnet-sonarscanner\10.4.1\tools\netcoreapp3.1\any\SonarQube.Analysis.xml contains only comments.

Thank you.
P.

4

Hi,

This warning, leads me to think you didn’t specify sonar.host.url and thus the analyzer defaulted to trying to authenticate to sonarqube.io. However, this

makes me doubt that.

So first, was the URL you redacted the correct one for your SonarQube instance? And assuming it was, where/how did you specify it? Specifically, was this on the command line, in “extra arguments” in an XML file, some other place…?

 
Thx,
Ann

5

Hi Ann,

I specified the URL for my SQ instance in the command line via /d:sonar.host.url=<valid_url>. You can see my full command line in the Reproduction Steps above. The URL is valid because it works with the other .net scanner, the UI via a browser, and also for API calls. The XML file mentioned in the verbose output (“Default properties file was found at […]“) contains only comments. I also made sure that there are no conflicting environment variables. In any case, the command line is supposed to override all other arguments, isn’t it?

BTW, I, too, was surprised by the warning about sonarqube.io. It’s as if the scanner is oblivious to the parameters I pass via the command line, i.e. the host URL (hence the warning) and the name of the project (hence “component=unknown”). The only other “explanation” I could think of is that I access the SQ instance via http and perhaps passing token information over clear-text protocols is not allowed any more.

Thanks for your help,
P.

6

Hi,

Thanks for checking and confirming. You mentioned that the failure is quite recent and that this was working 2 weeks ago.

You’re using the latest version of the scanner, 10.4.1, which was released on the 23th, so… there we go.

I’m going to flag this for the team. And in the meantime, you might want to try rolling back.

 
Ann

8

Hello @panosp

the two warnings you see are generated here:

As you can see, these warnings are only generated when the server returns 403 Forbidden or 401 Unauthorized. Also, the warning is printed no matter whether the server url was specified by you or not.

We did not change that part of the code base in the last releases.

We use Basic authentication when we contact the server with the SonarScanner for .Net.

works with the other .net scanner

Do you mean sonar-scanner-10.4.1.124928-net-framework.zip?

If so, can you please provide the .Net Runtime version you are using when you call dotnet sonarscanner by calling dotnet --version?

access the SQ instance via http and perhaps passing token information over clear-text protocols is not allowed any more

This would indeed be a explanation but in that case the net-framework (exe) of the scanner should also fail.

Our internal scanner tests always use http, so I’m not aware of any restrictions that might cause clear text basic authentication failures.

Can you provide some more details about you SonarQube server setup? Is the server behind a reverse proxy (like e.g. nginx) that may manipulate or remove the authentication header of the request?

10

Hi Martin,

dotnet --version returns 9.0.305. I also tried running the scanner on 8.0.410 (using global.json) and got the same result.

When I said “other .net scanner” I meant SonarScanner for MSBuild 10.1 for .NET Framework. This still works ok.

My SonarQube server is indeed behind a proxy, but the latter doesn’t seem to be the problem, because the following script (when used with a user token) returns a valid json answer:

$token  = "squ_..."
$baseUrl = "<the same url>"

$h=@{ Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("${token}:")) }
Invoke-RestMethod -Method Get -Uri "$baseUrl/api/projects/search?ps=1" -Headers $h -TimeoutSec 30 -Verbose

What puzzles me is that the installation is not new. Everything used to work fine a few days ago and it isn’t clear what has changed (apart from the version of the scanner). However, this is probably a coincidence, because after I encountered the problem I downgraded the scanner all the way to version 7 and got the same result (authentication error) every time.

Thank you for your help,
P.

11

Hello @panosp

I suspect that the proxy is causing the problems, because the .Net Framework version of the scanner is working. There are differences between the HttpClient from .Net Core vs. .Net Framework with respect to proxy handling.

If the proxy is a forward proxy, please make sure your Windows system is configured correctly.

  1. Make sure, the proxy settings on your Windows 10 machine are set correctly. See here for instructions. (The PowerShell script you have shown indicates that this is already done properly, but please double check).
  2. If this doesn’t help please set the proxy environment variables described in the Remarks here.

Do you have access to the logs of the proxy? If so, can you see the scanner request and the (transformed) request it forwards?

12

Hi Martin,

The problem was indeed with the proxy configuration. We had added the HTTP_PROXY and NO_PROXY environment variables to fix a different issue. The server’s address was among those listed in NO_PROXY. However, it seems that .NET does not support partial IP matching in NO_PROXY, although subdomains are OK. When I replaced the partial IP address of the server with the full one everything worked as expected.

Thanks for your help,
P.

1 Like
14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.