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

Running docker commands against Gitea registry results in a call against ROOT_URL #9929

New Issue
Closed
opened 2025-11-02 08:53:19 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2025-11-02 08:53:19 -06:00
Owner
Copy Link

Originally created by @scubbo on GitHub (Dec 5, 2022).

Description

See this repo - when running docker commands (docker login, docker pull, etc.) against a registry, a call is made against the server's ROOT_URL. If there is no server available at the ROOT_URL, this will result in an error. This can result in issues when the ROOT_URL refers to the public domain name of the Gitea service, but an image provided by the registry that is a prerequisite for setting up the public domain name is referenced by an internal domain name.

Gitea Version

Gitea version 1.18.0+rc1 built with GNU Make 4.3, go1.19.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?

Kubernetes in the original situation; docker-compose in the minimal reproduction.

Database

None

Originally created by @scubbo on GitHub (Dec 5, 2022). ### Description See [this repo](https://github.com/scubbo/possible-gitea-bug) - when running `docker` commands (`docker login`, `docker pull`, etc.) against a registry, a call is made against the server's `ROOT_URL`. If there is no server available at the `ROOT_URL`, this will result in an error. This can result in issues when the `ROOT_URL` refers to the public domain name of the Gitea service, but an image provided by the registry that is a prerequisite for setting up the public domain name is referenced by an internal domain name. ### Gitea Version Gitea version 1.18.0+rc1 built with GNU Make 4.3, go1.19.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? Kubernetes in the original situation; docker-compose in the minimal reproduction. ### Database None
GiteaMirror added the topic/packagestype/bug labels 2025-11-02 08:53:19 -06:00
GiteaMirror commented 2025-11-02 08:53:20 -06:00
Author
Owner
Copy Link

@KN4CK3R commented on GitHub (Dec 5, 2022):

You set ROOT_URL to something non-existing. Why should that work?

In your stackoverflow question you describe an "internal call" to the wrong domain. Gitea does not perform a request. The usual docker login flow is to query /v2. This will respond with Unauthorized and an url to obtain the ticket from.

77f50356f4/routers/api/packages/container/container.go (L114-L119)

Here you see the url is build using setting.AppURL which is influenced by your ROOT_URL setting. Your curl request succeeds because the basic auth handles the login but that's not used by docker.

@KN4CK3R commented on GitHub (Dec 5, 2022): You set ROOT_URL to something non-existing. Why should that work? In your stackoverflow question you describe an "internal call" to the wrong domain. Gitea does not perform a request. The usual docker login flow is to query `/v2`. This will respond with `Unauthorized` and an url to obtain the ticket from. https://github.com/go-gitea/gitea/blob/77f50356f4dd108b1e35b1a706269573aeaf98f1/routers/api/packages/container/container.go#L114-L119 Here you see the url is build using `setting.AppURL` which is influenced by your `ROOT_URL` setting. Your curl request succeeds because the basic auth handles the login but that's not used by docker.
GiteaMirror commented 2025-11-02 08:53:20 -06:00
Author
Owner
Copy Link

@scubbo commented on GitHub (Dec 5, 2022):

You set ROOT_URL to something non-existing. Why should that work?

Naïvely, for operations that do not require Gitea knowing it's own URL (like generating a git clone link), there's no reason to think that it wouldn't. Sure, a non-existent ROOT_URL is clearly not correct - but it's surprising that it results in breakages of APIs that appear to have nothing to do with the ROOT_URL itself.

That said, your explanation of the authentication mechanism makes it clear why this behaviour happens, and why addressing it would not be desirable. Thanks for the explanation!

@scubbo commented on GitHub (Dec 5, 2022): > You set ROOT_URL to something non-existing. Why should that work? Naïvely, for operations that do not require Gitea knowing it's own URL (like generating a `git clone` link), there's no reason to think that it _wouldn't_. Sure, a non-existent `ROOT_URL` is clearly not *correct* - but it's surprising that it results in breakages of APIs that appear to have nothing to do with the `ROOT_URL` itself. That said, your explanation of the authentication mechanism makes it clear why this behaviour happens, and why addressing it would not be desirable. Thanks for the explanation!
GiteaMirror commented 2025-11-02 08:53:20 -06:00
Author
Owner
Copy Link

@scubbo commented on GitHub (Jan 4, 2023):

Basically I was looking for Multi-domain support - I want to be able to access my Gitea instance via an internal Domain Name (which resolves directly via my Router's DNS override) or via an external Domain Name (resolved by DNS servers out on the broader Internet), and moreover want to be able to access the former even if the latter is inaccessible.

@scubbo commented on GitHub (Jan 4, 2023): Basically I was looking for [Multi-domain support](https://github.com/go-gitea/gitea/issues/19345) - I want to be able to access my Gitea instance via an internal Domain Name (which resolves directly via my Router's DNS override) _or_ via an external Domain Name (resolved by DNS servers out on the broader Internet), and moreover want to be able to access the former even if the latter is inaccessible.
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 topic/packages type/bug
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#9929
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?