github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Gitea OAuth provider is redirecting to just the path of redirect_uri, not the entire value #12734

New Issue
Closed
opened 2025-11-02 10:19:26 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-11-02 10:19:26 -06:00
Owner
Copy Link

Originally created by @nickdevereaux on GitHub (Mar 25, 2024).

Description

Confirmed with https://oauthdebugger.com/

The provider doesn't redirect to the full URL, redirecting to only the path which results in a request to the gitea instance, not the calling website

You can see in the image below where the orange redaction matches. The redirect_uri is http://localhost:5209 but the Location header Gitea sends back is itself instead of the localhost uri.

image

Gitea Version

1.21.9

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/nickdevereaux/36900fd90b2e470ba4f221566281386a

Screenshots

No response

Git Version

2.37.1

Operating System

Windows

How are you running Gitea?

Windows Services with executable gitea-1.21.9-windows-4.0-386.exe

Database

MSSQL

Originally created by @nickdevereaux on GitHub (Mar 25, 2024). ### Description Confirmed with https://oauthdebugger.com/ The provider doesn't redirect to the full URL, redirecting to only the path which results in a request to the gitea instance, not the calling website You can see in the image below where the orange redaction matches. The `redirect_uri` is `http://localhost:5209` but the `Location` header Gitea sends back is itself instead of the localhost uri. <img width="694" alt="image" src="https://github.com/go-gitea/gitea/assets/236895/df042d40-5d47-403f-b585-0a59d692b243"> ### Gitea Version 1.21.9 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist https://gist.github.com/nickdevereaux/36900fd90b2e470ba4f221566281386a ### Screenshots _No response_ ### Git Version 2.37.1 ### Operating System Windows ### How are you running Gitea? Windows Services with executable `gitea-1.21.9-windows-4.0-386.exe` ### Database MSSQL
GiteaMirror added the issue/needs-feedback label 2025-11-02 10:19:26 -06:00
GiteaMirror commented 2025-11-02 10:19:27 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 26, 2024):

No idea why it would happen.

Are you using some reverse proxy and it is doing some rewriting to responses?

Could you provide a reproducible setup (eg, by docker or something) with detailed steps then help to reproduce and debug?

Confirmed with https://oauthdebugger.com/
Can you reproduce the bug on the Gitea demo site? No

If it can't be reproduced on try.gitea.io, then TBH it doesn't seem to be a bug on Gitea side ....

@wxiaoguang commented on GitHub (Mar 26, 2024): No idea why it would happen. Are you using some reverse proxy and it is doing some rewriting to responses? Could you provide a reproducible setup (eg, by docker or something) with detailed steps then help to reproduce and debug? ---- > Confirmed with https://oauthdebugger.com/ > Can you reproduce the bug on the Gitea demo site? No If it can't be reproduced on try.gitea.io, then TBH it doesn't seem to be a bug on Gitea side ....
GiteaMirror commented 2025-11-02 10:19:27 -06:00
Author
Owner
Copy Link

@nickdevereaux commented on GitHub (Mar 26, 2024):

I'd need admin privileges to register the app on try.gitea.io wouldn't I? I'm not sure that's possible?

Either way I think you've cracked it @wxiaoguang, thank you, it is indeed behind a reverse proxy. I suspect the issue lies in there.

@nickdevereaux commented on GitHub (Mar 26, 2024): I'd need admin privileges to register the app on try.gitea.io wouldn't I? I'm not sure that's possible? Either way I think you've cracked it @wxiaoguang, thank you, it is indeed behind a reverse proxy. I suspect the issue lies in there.
GiteaMirror commented 2025-11-02 10:19:27 -06:00
Author
Owner
Copy Link

@punmechanic commented on GitHub (May 5, 2024):

No idea why it would happen.

Are you using some reverse proxy and it is doing some rewriting to responses?

Could you provide a reproducible setup (eg, by docker or something) with detailed steps then help to reproduce and debug?

Confirmed with https://oauthdebugger.com/
Can you reproduce the bug on the Gitea demo site? No

If it can't be reproduced on try.gitea.io, then TBH it doesn't seem to be a bug on Gitea side ....

I'm not sure if I should make this a new issue, but I was able to replicate this issue with a relatively trivial set up of Traefik and Gitea in Docker, with Traefik acting as a reverse proxy.

You find the code here.

The Gitea configuration is as follows - from gitea.yaml:

      - GITEA__service__ALLOW_ONLY_EXTERNAL_REGISTRATION=true
      - GITEA__openid__ENABLE_OPENID_SIGNIN=true
      - GITEA__openid__ENABLE_OPENID_SIGNUP=true
      - GITEA__openid__WHITELISTED_URIS=https://sso.aredherring.tech/

After starting Gitea, I create a new repo and follow the instructions I wrote in the readme:

- Authentication Type: OAuth2
- Authentication Name: keycloak
- OAuth2 Provider: OpenID Connect
- Client ID: gitea
- Client Secret: `cd terraform/keycloak && tofu output -raw gitea_client_secret`
- OpenID Connect Auto Discovery URL: https://sso.aredherring.tech/realms/homelab

Attempting to then use Keycloak to login presents me with a redirect to the following URL:

https://gitea.aredherring.tech/user/oauth2/?client_id=gitea&redirect_uri=https%3A%2F%2Fgitea.aredherring.tech%2Fuser%2Foauth2%2Fkeycloak%2Fcallback&response_type=code&scope=openid&state=315e3deb-efed-4407-a787-6bb962f7c115

I can see in the browser history that there is no redirection to https://sso.aredherring.tech/realms/homelab. I can also verify that Gitea is able to reach the discovery URL listed, that ${discovery_url}/.well-known/openid-configuration does return the correct output (inputting the wrong URL causes Gitea to emit an error), and the only logs in the console (after the obligatory start-up logs) on a fresh Gitea instance are:

2024/05/05 18:37:35 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/login?redirect_to=%2f for 10.0.0.2:0, 200 OK in 2.5ms @ auth/auth.go:146(auth.SignIn)
2024/05/05 18:37:38 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/oauth2/keycloak for 10.0.0.2:0, 307 Temporary Redirect in 1.4ms @ auth/oauth.go:847(auth.SignInOAuth)
2024/05/05 18:37:38 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/oauth2/?client_id=gitea&redirect_uri=https%3A%2F%2Fgitea.aredherring.tech%2Fuser%2Foauth2%2Fkeycloak%2Fcallback&response_type=code&scope=openid&state=315e3deb-efed-4407-a787-6bb962f7c115 for 10.0.0.2:0, 404 Not Found in 2.2ms @ context/repo.go:425(context.RepoAssignment)
@punmechanic commented on GitHub (May 5, 2024): > No idea why it would happen. > > Are you using some reverse proxy and it is doing some rewriting to responses? > > Could you provide a reproducible setup (eg, by docker or something) with detailed steps then help to reproduce and debug? > > > Confirmed with https://oauthdebugger.com/ > > Can you reproduce the bug on the Gitea demo site? No > > If it can't be reproduced on try.gitea.io, then TBH it doesn't seem to be a bug on Gitea side .... I'm not sure if I should make this a new issue, but I was able to replicate this issue with a relatively trivial set up of Traefik and Gitea in Docker, with Traefik acting as a reverse proxy. You find the code [here](https://github.com/punmechanic/homelab/). The Gitea configuration is as follows - from gitea.yaml: ``` - GITEA__service__ALLOW_ONLY_EXTERNAL_REGISTRATION=true - GITEA__openid__ENABLE_OPENID_SIGNIN=true - GITEA__openid__ENABLE_OPENID_SIGNUP=true - GITEA__openid__WHITELISTED_URIS=https://sso.aredherring.tech/ ``` After starting Gitea, I create a new repo and follow the instructions I wrote in the readme: ``` - Authentication Type: OAuth2 - Authentication Name: keycloak - OAuth2 Provider: OpenID Connect - Client ID: gitea - Client Secret: `cd terraform/keycloak && tofu output -raw gitea_client_secret` - OpenID Connect Auto Discovery URL: https://sso.aredherring.tech/realms/homelab ``` Attempting to then use Keycloak to login presents me with a redirect to the following URL: > https://gitea.aredherring.tech/user/oauth2/?client_id=gitea&redirect_uri=https%3A%2F%2Fgitea.aredherring.tech%2Fuser%2Foauth2%2Fkeycloak%2Fcallback&response_type=code&scope=openid&state=315e3deb-efed-4407-a787-6bb962f7c115 I can see in the browser history that there is no redirection to `https://sso.aredherring.tech/realms/homelab`. I can also verify that Gitea is able to reach the discovery URL listed, that `${discovery_url}/.well-known/openid-configuration` does return the correct output (inputting the wrong URL causes Gitea to emit an error), and the only logs in the console (after the obligatory start-up logs) on a fresh Gitea instance are: ``` 2024/05/05 18:37:35 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/login?redirect_to=%2f for 10.0.0.2:0, 200 OK in 2.5ms @ auth/auth.go:146(auth.SignIn) 2024/05/05 18:37:38 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/oauth2/keycloak for 10.0.0.2:0, 307 Temporary Redirect in 1.4ms @ auth/oauth.go:847(auth.SignInOAuth) 2024/05/05 18:37:38 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/oauth2/?client_id=gitea&redirect_uri=https%3A%2F%2Fgitea.aredherring.tech%2Fuser%2Foauth2%2Fkeycloak%2Fcallback&response_type=code&scope=openid&state=315e3deb-efed-4407-a787-6bb962f7c115 for 10.0.0.2:0, 404 Not Found in 2.2ms @ context/repo.go:425(context.RepoAssignment) ```
GiteaMirror commented 2025-11-02 10:19:27 -06:00
Author
Owner
Copy Link

@punmechanic commented on GitHub (May 7, 2024):

I resolved this myself. This issue occurs when you specify the root of the openid provider, i.e, https://sso.aredherring.tech/realms/homelab instead of the fully qualified path to .well-known/openid-configuration ie https://sso.aredherring.tech/realms/homelab/.well-known/openid-configuration.

@punmechanic commented on GitHub (May 7, 2024): I resolved this myself. This issue occurs when you specify the root of the openid provider, i.e, `https://sso.aredherring.tech/realms/homelab` instead of the fully qualified path to `.well-known/openid-configuration` ie `https://sso.aredherring.tech/realms/homelab/.well-known/openid-configuration`.
GiteaMirror commented 2025-11-02 10:19:27 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (May 7, 2024):

I resolved this myself. This issue occurs when you specify the root of the openid provider, i.e, https://sso.aredherring.tech/realms/homelab instead of the fully qualified path to .well-known/openid-configuration ie https://sso.aredherring.tech/realms/homelab/.well-known/openid-configuration.

So I think this is not a bug but a configuration problem.

@lunny commented on GitHub (May 7, 2024): > I resolved this myself. This issue occurs when you specify the root of the openid provider, i.e, `https://sso.aredherring.tech/realms/homelab` instead of the fully qualified path to `.well-known/openid-configuration` ie `https://sso.aredherring.tech/realms/homelab/.well-known/openid-configuration`. So I think this is not a bug but a configuration problem.
GiteaMirror commented 2025-11-02 10:19:28 -06:00
Author
Owner
Copy Link

@punmechanic commented on GitHub (May 7, 2024):

It's a configuration problem, but I received false confidence in the green check mark that said things were ok.

A potential improvement would be to either:

  • Have an example value that shows the .well-known/openid-configuration (Some SDKs don't require this to be here, which is why I was confused) or
  • Send a request when adding the authorization source that tests that a valid openid-configuration is received from the endpoint.

I understand that Gitea does something to validate the authorization source right now, but it's clearly not checking that an openid configuration is returned. Looks like it just verifies that the URL is valid, then hands it off to Gothic, which is what is being relied on to verify the openid configuration is correct. So maybe this is a gothic bug?

Either of these things would help prevent this from happening in the future :)

@punmechanic commented on GitHub (May 7, 2024): It's a configuration problem, but I received false confidence in the green check mark that said things were ok. A potential improvement would be to either: * Have an example value that shows the `.well-known/openid-configuration` (Some SDKs don't require this to be here, which is why I was confused) *or* * Send a request when adding the authorization source that tests that a valid `openid-configuration` is received from the endpoint. I understand that Gitea does _something_ to validate the authorization source right now, but it's clearly not checking that an openid configuration is returned. [Looks like it just verifies that the URL is valid](https://github.com/go-gitea/gitea/blob/main/routers/web/admin/auths.go#L273), then hands it off to Gothic, which is what is being relied on to verify the openid configuration is correct. So maybe this is a gothic bug? Either of these things would help prevent this from happening in the future :)
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/needs-feedback
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#12734
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?