Oauth2 integration with gitlab when sonar is running behind an nginx proxy

Get help SonarQube
#1

This refers to SonarQube 8.6 developer edition.

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:

“GET /oauth/authorize?response_type=code&client_id=<TOKEN_OMITTED>&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2Foauth2%2Fcallback%2Fgitlab&scope=read_user&state=f2gfcctjlnt1kbk59og3felnqu HTTP/2.0” 200 8312 “https://sonar.powercastco.com/sessions/new” “Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0” 3.80

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.

#2

I have some further analysis.

In my setting, sonarqube thinks it is executing at http://locahost:9000. From the outside, however, it should be executing at https://sonar.powercastco.com/. What it puts in its GET request is
redirect_uri=“http://localhost:9000/oauth2/callback/gitlab” because that’s what it thinks the URL ought to be.

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.

What would this setting be?

#3

Hi, this settings is accessible in SonarQube with admin permission, in Administration->configuration->general, and is named “Server Base URL” (sonar.core.serverBaseURL).

#4

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.

  1. 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.

  2. 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;

     	 proxy_redirect off;


 	 proxy_set_header Host $host;
 	 proxy_set_header X-Real-IP $remote_addr;
 	 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 	 proxy_set_header X-Forwarded-Proto https;
 }

With these settings, where things stand are:

  • The sonar log in page shows the gitlab login as an option
  • When I click on the gitlab button, I’m redirected to the gitlab login page
  • When I log into gitlab, I bounce back to a not authorized page in sonar.
  • When I browse back to gitlab, I find that I’m logged into gitlab.

So…

  • SonarQube is talking to gitlab, at least to the point where it goes to a gitlab login page.
  • I can successfully log into gitlab
  • Once I log into gitlab, something goes wrong with the return OAUTH2 process for actually logging into sonarqube.
#5

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.

#6

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.

#7

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.

http upstream request: “/oauth2/callback/gitlab?code=653a8397bb24e75130f57956585371c4574f8b95ba65c42bb288f4816273317a&state=pl9m22qi8otbse69tarbtokpfq”

… 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.