we observe the following Problem with SQ version ( 6.7.1 ) and Sonar Lint for Eclipse (but it can be reproduced without Sonar Lint).
Our SonarQube is running behind a proxy and is configured to authenticate users based on the “X-Forwarded-User” and “X-Forwarded-Groups”, … Headers (Thanks for implementing that by the way). This works perfectly fine for the Web-UI, but sadly not when Sonar Lint is used.
We’ve analyzed all the logs and there is basically only one request which is made by Sonar Lint. It requests “sonarqube/api/authentication/validate” which returns with Status 200, so we do not have a connection issue here. We checked what “sonarqube/api/authentication/validate” returns and here is the probable bug. If you visit the Web-UI first, a “JWT-Session” cookie is set and “sonarqube/api/authentication/validate” will return {“valid”:true} if the cookie is set. But if you remove all cookies and access “sonarqube/api/authentication/validate” directly as it is done by Sonar Lint, it returns {“valid”:false}.
The only “workaround” we’ve found is the following one: Our Proxy only accepts basic-auth, so we configure Sonar Lint to use a username + password to pass the proxy. If we now remove the automatically created user and add it manually again while setting the password to the one our proxy accepts, it works…
I don’t understand exactly what is your problem, as you need to use a user token or a login/password in SonarLint in order to connect it to SonarQube.
Have you correctly set it in SonarLint ?
About api/authentication/validate, it will either return true when the request contains the BASIC authorization header (user token or login/password), or when a JWT session exists in the HTTP request ()this last feature should not be used in the case of SonarLint).
let me try to explain it a little bit more detailed: So with SQ 6.7( or even earlier ?) you’ve integrated the “web.sso.login” feature. That feature allows me to set a proxy in front of my SQ instance and let the proxy handle the authorization. If the proxy says “Okay, I know that user” it will configure several headers (e.g. X-Forwarded-User=Marvin) and will forward it so SQ. SQ will detect that header if “web.sso.login” is set to “enabled”.
This works perfectly for a normal web-access, but NOT for SonarLint.
In my example my proxy accepts basic-auth, so I need to configure the user and the password for my proxy in SonarLint (e.g. User: MarvinProxyUser Password: SecretPassword)
Than SonarLint is connecting to the Server through my proxy who sets the headers.
And now the bug is, that api/authentication/validate does not care about the headers. It will only check for basic auth or the JWT token as you mentioned.
