I’m running sonar behind an NGINX proxy in order to use https:. That works. I’m now attempting to integrate sonarqube with our gitlab server for authentication, group sharing, etc…
I followed the instructions to set up the application on both gitlab and sonar.
When I attempt to sign in using my gitlab account, I receive the “Redirect URI included is not valid”
I pulled the gitlab logs for the request and found the following:
While I’m not sure what the %3A stuff is, the redirect_uri as reported by gitlab seems to be http://localhost:9000/
This is the port that sonar itself is executing on, locally behind the nginx proxy.
Can someone who has successfully configured sonar behind an nginx proxy and gotten gitlab oauth2 to work done this post their nginx.conf file that they use on their sonar server? I suspect that the problem is with that because that’s the place where https://sonar.myhost/ is mapped to http://localhost:9000.
So, my guess is that there is some setting in the configuration file that ought to tell sonar that from the perspective of the outside world it’s executing at https://sonar.powercastco.com[:443]/ and that’s what it should be using in the oauth parameters.
Hi, this settings is accessible in SonarQube with admin permission, in Administration->configuration->general, and is named “Server Base URL” (sonar.core.serverBaseURL).
Thank you. That got me to the next problem. This post will probably make me look foolish, but I’ve added all of the mistakes that I made in the hope that this checklist will help somebody else.
Ensure that the sonar system and the gitlab system recognize each other’s SSL certificates. Note that sonar is a java application so you need to add the certificate to the JVM key store in addition to the system’s key store used for web browsers and wget.
Ensure that the NGINX settings are proper. Right now the settings that I’m using are:
location / {
proxy_pass localhost:9000 – the support system doesn’t like a link to localhost in the post. Go figure…
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 ht
tp_504;
The lastest failure is accompanied with a stack trace in the web.log file. The error is:
2021.01.15 20:44:54 WARN web[AXcHyxc+YhHC0KS5AAAP][o.s.s.a.AuthenticationError] Fail to callback authentication with ‘gitlab’
java.lang.IllegalStateException: java.io.IOException: Unable to tunnel through proxy. Proxy returns “HTTP/1.1 400 Bad Request”
at org.sonar.auth.gitlab.GitLabIdentityProvider.callback(GitLabIdentityProvider.java:104)
So what is going on is an interaction between the oauth2 process and the proxy support.
At this specific step, do you have any interesting information in your browser inspector? You want to look at parameters, headers, to find maybe an incorrect redirect URL or a weird payload.
You can also increase log verbosity to DEBUG in SonarQube, to catch more information about the steps that fails.
Sonarqube’s web.log shows that the login failed because the proxy returned a 400. So I believe the error is coming from the copy of NGINX running on my sonar host that is proxying connections behind an https connection, running on the default port 443.
I examined the NGINX logs for the nginx instance running on my gitlab server and it never generated an error, so believe this is confirming evidence that isolates the problem to the nginx server running on the sonar system.
I enabled NGINX error debugging and this is the relevant request where things started to go off the rails.
… elided a bunch of debugging traces that seemed to be tracing the setup of the HTTP request
for the proxy …
client sent invalid request while reading client request line, client: 192.168.0.4, server: , request: “CONNECT gitlab.powercastco.com:443 HTTP/1.1”
In this case, 192,168.0.4 is the IP address of our sonar server, so this seems to be an outgoing request from “localhost” to gitlab.powercastco.com, port 443.
2021/01/20 15:37:25 [debug] 3833#3833: *769 HTTP/1.1 400 Bad Request
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 20 Jan 2021 15:37:25 GMT
Content-Type: text/html
Content-Length: 182
Connection: close
I agree that the problem is likely a proxy setting of some form.