Hi, thanks for the clarification.
That’s odd. I wonder where the port 8443 gets picked up then, and by whom. As far as I know, the
$host variable doesn’t contain any port (right?), so:
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
would not pass NginX’s port to SQ. Say, if the
<sonarqube-url> is sq.example.com, the HTTP headers would look like this:
sonar.core.serverBaseURL=https://sq.example.com, so I would be inclined to think the issue with the redirect is not on SQ’s side. I don’t see how SQ can even know that there’s a non-standard port involved.
It’s hard to know without actually seeing the entire setup . But I would imagine the issue comes from either NginX, when it processes the redirect (which should flow through it again), or from your SAML IdP.
The typical workflow of an auth request would be:
- User accesses the App
- NginX handles the request
- NginX passes the request to SQ
- SQ prepares the SAML data, and redirects to the IdP for authentication
- Request passes through NginX again – This is probably where the problem starts
- Request is handled by the IdP
- IdP redirects back to the SP
- NginX get the request, passes it to SQ again
- SQ gets the SAML data, authenticates the user
- SQ redirects to itself (like, home page)
- Request goes through NginX again
- NginX forwards the request to SQ
But to make matters even more complex, here, you have Kubernetes in front of the whole shebang .
Points I would investigate:
- Where is the final redirect going to (after successful auth)? If, until that point, the port was not in the URL yet, it might be on NginX’s side (redirecting to itself, like
Location /projects, bypassing Kubernetes?)
- How is the request passed from SQ -> NginX -> ?Kubernetes? -> IdP ? I could imagine the port is added there at some point.
Let me know how it goes .