github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-16 13:20:06 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

OpenID Connect Login navigating to 404 (Wrong endpoint) #2834

New Issue
Closed
opened 2025-11-02 04:50:15 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-02 04:50:15 -06:00
Owner
Copy Link

Originally created by @uncled1023 on GitHub (Jan 28, 2019).

  • 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

image

Originally created by @uncled1023 on GitHub (Jan 28, 2019). - Gitea version (or commit ref): 1.7 - Git version: 2.16.1.windows.2 - Operating system: Windows Server 2016 Datacenter - Database (use `[x]`): - [ ] PostgreSQL - [X] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [X] 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=<myclientId>&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 ![image](https://user-images.githubusercontent.com/2438810/51867223-cfcf8780-22ff-11e9-8926-9d99a80923d3.png)
GiteaMirror added the topic/deploymentissue/not-a-bug labels 2025-11-02 04:50:15 -06:00
GiteaMirror commented 2025-11-02 04:50:16 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

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.

@uncled1023 commented on GitHub (Feb 2, 2019): 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.
GiteaMirror commented 2025-11-02 04:50:16 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

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

@zeripath commented on GitHub (Feb 2, 2019): Could you try a `curl -I --path-as-is ` just to check that it's definitely not being changed by the browser.
GiteaMirror commented 2025-11-02 04:50:16 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

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 commented on GitHub (Feb 2, 2019): ~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.
GiteaMirror commented 2025-11-02 04:50:16 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

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
@uncled1023 commented on GitHub (Feb 2, 2019): 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 ```
GiteaMirror commented 2025-11-02 04:50:17 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

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 commented on GitHub (Feb 2, 2019): 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?
GiteaMirror commented 2025-11-02 04:50:17 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

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.

@zeripath commented on GitHub (Feb 2, 2019): 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.
GiteaMirror commented 2025-11-02 04:50:18 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

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

image

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.

image

Maybe it's something IIS is doing?

@uncled1023 commented on GitHub (Feb 2, 2019): Yea, i'm positive it's passing the correct URL into http.Redirect() ![image](https://user-images.githubusercontent.com/2438810/52162360-ad36c900-2687-11e9-9c01-b665dd79f1be.png) 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. ![image](https://user-images.githubusercontent.com/2438810/52162377-0141ad80-2688-11e9-9c51-dac98fba890e.png) Maybe it's something IIS is doing?
GiteaMirror commented 2025-11-02 04:50:18 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

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.

@zeripath commented on GitHub (Feb 2, 2019): 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.
GiteaMirror commented 2025-11-02 04:50:18 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

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

@uncled1023 commented on GitHub (Feb 2, 2019): I agree. I'll dig into the rewrite rules and see what I can come up with.
GiteaMirror commented 2025-11-02 04:50:18 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

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.

@uncled1023 commented on GitHub (Feb 2, 2019): 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.
GiteaMirror commented 2025-11-02 04:50:18 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

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?

@zeripath commented on GitHub (Feb 2, 2019): 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?
GiteaMirror commented 2025-11-02 04:50:18 -06:00
Author
Owner
Copy Link

@uncled1023 commented on GitHub (Feb 2, 2019):

I'll write something up and make a PR

@uncled1023 commented on GitHub (Feb 2, 2019): I'll write something up and make a PR
GiteaMirror commented 2025-11-02 04:50:19 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 2, 2019):

Cool. Ok I'll close this issue.

@zeripath commented on GitHub (Feb 2, 2019): Cool. Ok I'll close this issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/not-a-bug topic/deployment
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2834
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?