OpenID Connect Login navigating to 404 (Wrong endpoint)

[uncled1023]

• Gitea version (or commit ref): 1.7
• Git version: 2.16.1.windows.2
• Operating system: Windows Server 2016 Datacenter
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:
  Nothing interesting in the logs

Description

After setting up an OpenID Connect authentication source, and clicking the 'Sign In with OpenID Connect' button, the page then goes to a 404 page, with the url being what seems to be the authorize endpoint, but appended to the current domain.

My thoughts is that since my openId provider has the same domain but different subdomain as my hosted gitea instance, that gitea is just taking the endpoint and appending it to it's current url.

URL for login button: https://git.teknik.io/user/oauth2/TeknikIdentity
URL after clicking login: https://git.teknik.io/connect/authorize?client_id=&redirect_uri=https%3A%2F%2Fgit.teknik.io%2Fuser%2Foauth2%2FTeknikIdentity%2Fcallback&response_type=code&scope=openid&state=<state_guid>

Here's my current config: https://p.teknik.io/gKeh8

I did try to set it up via a locally ran Gitea instance, and it worked just fine.

Screenshots

[uncled1023]

So I was able to duplicate it while debugging, and followed it to https://github.com/go-gitea/gitea/blob/master/modules/auth/oauth2/oauth2.go#L83 where it passed the correct URL into the http.Redirect function. At that point, I was unable to follow it anymore, but the resulting response had the location header with the incorrect URL. So I suspect something within GO's HTTP.Request() is altering the URL.

[zeripath]

Could you try a curl -I --path-as-is just to check that it's definitely not being changed by the browser.

[uncled1023]

Try that on the expected URL? (https://auth.teknik.io/connect/authorize)

Sorry, you meant the entry link for the OAuth.

Here are the results:

C:\Users\Administrator>curl -I --path-as-is https://git.teknik.io/user/oauth2/TeknikIdentity
HTTP/1.1 307 Temporary Redirect
Content-Length: 0
Content-Type: text/html; charset=utf-8
Location: https://git.teknik.io/connect/authorize?client_id=<myclientid>&redirect_uri=https%3A%2F%2Fgit.teknik.io%3A3000%2Fuser%2Foauth2%2FTeknikIdentity%2Fcallback&response_type=code&scope=openid&state=4d7e6e40-aeae-48a1-b563-c4df4b3c2306
Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
Set-Cookie: i_like_gitea=4dc06307979bbe2b; Path=/; HttpOnly
Set-Cookie: _csrf=_K-JhLglpBntwPab58ksylkIf006MTU0OTA5NzQzNzkyNTI4NDgwMA%3D%3D; Path=/; Expires=Sun, 03 Feb 2019 08:50:37 GMT; HttpOnly
Set-Cookie: _gothic_session=; Path=/; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Max-Age=0
Set-Cookie: _gothic_session=MTU0OTA5NzQzN3xOd3dBTkROVVFUUXlTa2syUzB4SFFrVlBSVTFKVXpjMFJrRmFVbE0yUlZjMFRrRTNVRmREUTFkWU5WSlJOVlJNU1V4Q1NWcFJTVUU9fK6P4p24PR27RwbWK5CbmSGhsZk4e3EY44pG-gKccWJ8; Path=/; Expires=Mon, 04 Mar 2019 08:50:37 GMT; Max-Age=2592000
X-Frame-Options: SAMEORIGIN
X-Powered-By: ARR/3.0
Date: Sat, 02 Feb 2019 08:50:37 GMT

Looks like it's not the browser.

[uncled1023]

Here is the same command, ran from the same terminal, but pointing at localhost.

C:\Users\Administrator>curl -I -k --path-as-is https://localhost:3000/user/oauth2/TeknikIdentity
HTTP/2 307
content-type: text/html; charset=utf-8
location: https://auth.teknik.io/connect/authorize?client_id=<myclientid>&redirect_uri=https%3A%2F%2Fgit.teknik.io%3A3000%2Fuser%2Foauth2%2FTeknikIdentity%2Fcallback&response_type=code&scope=openid&state=1887e856-62ad-4436-bef6-53f0025db896
set-cookie: lang=en-US; Path=/; Max-Age=2147483647
set-cookie: i_like_gitea=3ad767c5b0655be9; Path=/; HttpOnly
set-cookie: _csrf=ZhQmZjGO43jF3iDK30YFgnfR9Pk6MTU0OTA5Nzc5OTU5NTk4MjYwMA%3D%3D; Path=/; Expires=Sun, 03 Feb 2019 08:56:39 GMT; HttpOnly
set-cookie: _gothic_session=; Path=/; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Max-Age=0
set-cookie: _gothic_session=MTU0OTA5Nzc5OXxOd3dBTkVsRFUwaEdNemRIVFVFMlMxY3lWVXhKU0RKVE5WSlJWRnBFU1RWWVNrWlVWbEJQU0RkSFVWTmFURVpJV0ZaVVRWRlJTRUU9fC6G0_SOXlJuLsHbGJpMbFrW9vcUXaGmxucJFnhuW7Hu; Path=/; Expires=Mon, 04 Mar 2019 08:56:39 GMT; Max-Age=2592000
x-frame-options: SAMEORIGIN
date: Sat, 02 Feb 2019 08:56:39 GMT

[zeripath]

Ok. So you say it definitely passed the correct URL into http.Redirect? (You've definitely got it logged to Stdout?)

Another thing to check is that the response isn't proxied in some way so that it's not being wrapped.

Presumably, you're sitting Gitea behind a proxy is there any way it's munging the URL? I don't know if it's possible to stick some logging in there?

[zeripath]

Sorry just saw your reply. Are you running that localhost command on your git.teknik.io box?

Presuming you're running Gitea behind a proxy it would be helpful to see what comes out from Gitea before it gets to the proxy.

[uncled1023]

Yea, i'm positive it's passing the correct URL into http.Redirect()

And yea, i'm running that localhost command on the git.teknik.io box (as well as the original one).

Gitea is running being IIS which is doing a URL rewrite to inbound requests.

Maybe it's something IIS is doing?

[zeripath]

I think at this point blaming Microsoft is reasonable.

I have never configured IIS - so I think we're at the limit of my usefulness.

I bet it's something to do with it doing a reverse DNS lookup and then rewriting the host. You probably need to specifically allow Gitea to redirect to auth and turn off rewrites to those URLs. Reply with your fix though because it may be helpful for others and we consider adding something to the docs but I think I'll mark this issue invalid as the problem is not in Gitea.

[uncled1023]

I agree. I'll dig into the rewrite rules and see what I can come up with.

[uncled1023]

Well that was faster than I thought. After looking at the Failed Request logs to see exactly what it did, it turns out the Application Request Routing was changing the Location Header on it's way out. So I went into the configuration for the ARR, and lo and behold, there is a setting called 'Reverse rewrite host in response headers'. Switching that off allowed the URL to come through unaltered.

[zeripath]

Lol. Ok, I guess a troubleshooting docs addition might be helpful? If you could either put the change in here or make a PR we can get it in?

[uncled1023]

I'll write something up and make a PR

[zeripath]

Cool. Ok I'll close this issue.