Bearer link target only have one target - AppURL. #11584

New Issue

GiteaMirror · 2025-11-02T09:41:45-06:00

GiteaMirror commented

2025-11-02 09:41:45 -06:00

Originally created by @plomosits on GitHub (Sep 1, 2023).

Description

As i'm using Gitea Actions with act runner i have a problem that the Bearer redirect points to an "invalid" host from the perspective of the runner.

Gitea is running in a Kubernetes cluster and is a accessible via Ingress over gitea.example.com.
Ingress (gitea.example.com) -> Service (gitea-http:3000) -> Pod (gitea)
The parameters (GITHUB_SERVER_URL=http://gitea-http.gitea.svc:3000) for the runner will point directly to the service, which is perfectly fine.

BUT: If the runner wants to push the Docker image to the gitea repository, gitea answers the request with an 401 Unauthorized and the www-authenticate header.

curl -v -X POST http://gitea-http.gitea.svc:3000/v2/project-y/ms-go/blobs/uploads/
...
< HTTP/1.1 401 Unauthorized
< Www-Authenticate: Bearer realm="http://git.example.local/v2/token",service="container_registry",scope="*"

This is because the setting.AppURL is used instead of resolve the host dynamically.

ctx.Resp.Header().Add("WWW-Authenticate", `Bearer realm="`+setting.AppURL+`v2/token",service="container_registry",scope="*"`)

But the runner isn't able to resolve git.example.local.

My suggestion is

routers/api/packages/container/container.go:120

// using x-forwarded headers
realmUrl, err := url.Parse(fmt.Sprintf("%v://%v/", ctx.Req.Header.Get("X-Forwarded-Proto"), ctx.Req.Header.Get("X-Forwarded-Host")))
if err != nil {
	// using host header
	realmUrl, err = url.Parse(fmt.Sprintf("%v://%v/", "http", ctx.Req.Host))
}
if err != nil {
	// fallback
	realmUrl, err = url.Parse(setting.AppURL)
}

ctx.Resp.Header().Add("WWW-Authenticate", `Bearer realm="`+realmUrl.String()+`v2/token",service="container_registry",scope="*"`)

The effect would be

curl -v -X POST http://gitea-http.gitea.svc:3000/v2/project-y/ms-go/blobs/uploads/
...
< HTTP/1.1 401 Unauthorized
< Www-Authenticate: Bearer realm="http://gitea-http.gitea.svc:3000/v2/token",service="container_registry",scope="*"

Gitea Version

1.20.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

I'm running Gitea in a Kubernetes cluster configured with Helm Chart (https://dl.gitea.io/charts).
I'm also using actions with act_runner.

Database

PostgreSQL

Originally created by @plomosits on GitHub (Sep 1, 2023). ### Description As i'm using Gitea Actions with act runner i have a problem that the Bearer redirect points to an "invalid" host from the perspective of the runner. Gitea is running in a Kubernetes cluster and is a accessible via Ingress over gitea.example.com. Ingress (gitea.example.com) -> Service (gitea-http:3000) -> Pod (gitea) The parameters (GITHUB_SERVER_URL=http://gitea-http.gitea.svc:3000) for the runner will point directly to the service, which is perfectly fine. BUT: If the runner wants to push the Docker image to the gitea repository, gitea answers the request with an 401 Unauthorized and the www-authenticate header. ``` curl -v -X POST http://gitea-http.gitea.svc:3000/v2/project-y/ms-go/blobs/uploads/ ... < HTTP/1.1 401 Unauthorized < Www-Authenticate: Bearer realm="http://git.example.local/v2/token",service="container_registry",scope="*" ``` This is because the setting.AppURL is used instead of resolve the host dynamically. ``` ctx.Resp.Header().Add("WWW-Authenticate", `Bearer realm="`+setting.AppURL+`v2/token",service="container_registry",scope="*"`) ``` But the runner isn't able to resolve git.example.local. ### My suggestion is routers/api/packages/container/container.go:120 ``` // using x-forwarded headers realmUrl, err := url.Parse(fmt.Sprintf("%v://%v/", ctx.Req.Header.Get("X-Forwarded-Proto"), ctx.Req.Header.Get("X-Forwarded-Host"))) if err != nil { // using host header realmUrl, err = url.Parse(fmt.Sprintf("%v://%v/", "http", ctx.Req.Host)) } if err != nil { // fallback realmUrl, err = url.Parse(setting.AppURL) } ctx.Resp.Header().Add("WWW-Authenticate", `Bearer realm="`+realmUrl.String()+`v2/token",service="container_registry",scope="*"`) ``` ### The effect would be ``` curl -v -X POST http://gitea-http.gitea.svc:3000/v2/project-y/ms-go/blobs/uploads/ ... < HTTP/1.1 401 Unauthorized < Www-Authenticate: Bearer realm="http://gitea-http.gitea.svc:3000/v2/token",service="container_registry",scope="*" ``` ### Gitea Version 1.20.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? I'm running Gitea in a Kubernetes cluster configured with Helm Chart (https://dl.gitea.io/charts). I'm also using actions with act_runner. ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 09:41:45 -06:00

GiteaMirror closed this issue

2025-11-02 09:41:45 -06:00

GiteaMirror commented

2025-11-02 09:41:46 -06:00

@plomosits commented on GitHub (Sep 1, 2023):

#26872

@plomosits commented on GitHub (Sep 1, 2023): #26872

GiteaMirror commented

2025-11-02 09:41:46 -06:00

@wxiaoguang commented on GitHub (Sep 3, 2023):

But the runner isn't able to resolve git.example.local (or .com?)

I think this is the real problem. Why gitea.example.com can't be used? It should be used everywhere.

And I have read your PR, besides some nits, url.Parse(fmt.Sprintf("%v://%v/", "http", ctx.Req.Host)) is not right, because Gitea itself can serve HTTPS directly.

@wxiaoguang commented on GitHub (Sep 3, 2023): > But the runner isn't able to resolve git.example.local (or .com?) I think this is the real problem. Why `gitea.example.com` can't be used? It should be used everywhere. And I have read your PR, besides some nits, `url.Parse(fmt.Sprintf("%v://%v/", "http", ctx.Req.Host))` is not right, because Gitea itself can serve HTTPS directly.

GiteaMirror commented

2025-11-02 09:41:46 -06:00

@plomosits commented on GitHub (Sep 4, 2023):

Thank you @wxiaoguang for your feedback. You're right, now i will also check if there is a TLS connection.

@plomosits commented on GitHub (Sep 4, 2023): Thank you @wxiaoguang for your feedback. You're right, now i will also check if there is a TLS connection.

GiteaMirror commented

2025-11-02 09:41:46 -06:00

@wxiaoguang commented on GitHub (Sep 4, 2023):

I do no think guessing the absolute URL is a good solution for everyone. For example, if people use Gitea (HTTP) behinds nginx (HTTPS) but there is no "X-Forwared" headers, it will still be wrong.

The first question is: why gitea.example.com can't be used? It should be used everywhere.

@wxiaoguang commented on GitHub (Sep 4, 2023): I do no think guessing the absolute URL is a good solution for everyone. For example, if people use Gitea (HTTP) behinds nginx (HTTPS) but there is no "X-Forwared" headers, it will still be wrong. The first question is: why `gitea.example.com` can't be used? It should be used everywhere.

GiteaMirror commented

2025-11-02 09:41:47 -06:00

@lunny commented on GitHub (Sep 6, 2023):

You should set https://gitea.example.com as your root_url

@lunny commented on GitHub (Sep 6, 2023): You should set `https://gitea.example.com` as your root_url

GiteaMirror commented

2025-11-02 09:41:47 -06:00

@plomosits commented on GitHub (Sep 6, 2023):

Ok, thank you.

@plomosits commented on GitHub (Sep 6, 2023): Ok, thank you.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11584