SCANJLIB-230 Add warning when sonar.login (and sonar.token simultaneo…

[aleksandra-bozhinoska-sonarsource]

SCANJLIB-230

…usly) is used

I have determined the SonarQube Server version when the sonar.token property was introduced from the fix version of the following task.

How to test?
Run the scanner with both the sonar.token and sonar.login properties set, the following two warnings should be displayed in the logs:
11:28:24.316 WARN Both 'sonar.login' and 'sonar.token' (or the 'SONAR_TOKEN' env variable) are set, but only the latter will be used.
11:28:24.680 WARN Use of 'sonar.login' property has been deprecated in favor of 'sonar.token' (or the env variable alternative 'SONAR_TOKEN'). Please use the latter when passing a token.

However, to discuss:
As for this point of the task: ensure that token effectively has priority over basic auth (also check in the scanner engine of SQS and SQC)

• Not the case for the scanner engine (both in Server and Cloud) (due to for example line 90 in ScannerWsClientProvider.java in sonarqube - if the login property is present, it is not overriden).

[henryju]

I have a small doubt regarding the messages mentioning properties keys. In practice, users can set the token also using the env variable SONAR_TOKEN. So mentioning they defined sonar.token might be confusing.
Either we should "remember" the source of the token (maybe not an easy task), or every message should mention both?

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
92.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[aleksandra-bozhinoska-sonarsource]

• I was able to verify that when both sonar.login and sonar.token are set, the sonar.login value is used in the credentials.

• Another observation is that we have similar sonar.login deprecation log issued from the scanner engine (both SQS, SQC): DeprecatedPropertiesWarningGenerator.java.

[henryju]

So to sum up, we have a different behavior in the scanner bootstrapper than in the current scanner engine, right?

• scanner bootstrapper favors sonar.token
• scanner engine favors sonar.login

I don't think this is a big deal, since this has been deprecated for a long time, and we are even dropping username/password in the next SQS release.

[aleksandra-bozhinoska-sonarsource]

So to sum up, we have a different behavior in the scanner bootstrapper than in the current scanner engine, right?

• scanner bootstrapper favors sonar.token
• scanner engine favors sonar.login

I don't think this is a big deal, since this has been deprecated for a long time, and we are even dropping username/password in the next SQS release.

Yes, that's right.