OCI Registry uses AppURL (ROOT_URL) no matter which address the client is connecting to (more Multi-Domain fallout)
#29591
Comments
jessesanford
changed the title
AppURL (ROOT_URL) no matter which address the client is connecting to (More Multi-Domain fallout)
jessesanford
changed the title
AppURL (ROOT_URL) no matter which address the client is connecting to (More Multi-Domain fallout)AppURL (ROOT_URL) no matter which address the client is connecting to (more Multi-Domain fallout)
|
Added the packages label because of the specific topic but this issue is not really package related. Gitea simply does not have multi-domain support at the moment. |
|
The solution for this case is pretty simple @KN4CK3R. See my POC: https://github.com/jessesanford/gitea/blob/c2fffabcd5122d258360d4443b6e583fc62e28f1/routers/api/packages/container/container.go#L119-L131 Would it be worth crafting a PR for this? What are the chances of this getting approved and merged without a broader multi-domain solution. Given the incremental solutions so far: #19345 it would seem like we should be able to get this going right? |
|
@KN4CK3R Sorry to ping you directly, is there another maintainer I should be working with on this? Thank you for your help! |
|
Maybe |
FYI for those following this: https://github.com/jessesanford/gitea/pull/1/files#diff-36426f1aaff58f9b2084f7fc13593b237474e1d75a4e2883e0a44351e367ff76R125 Do you think that we would check for |
|
@wxiaoguang You did some work removing root url occurences. I don't know what other multi url systems do and what are best practices. For example I don't know if it is a good idea to allow every url the client passes in or if we need an allow list or something. |
|
The "X-Forwarded-* header" approach works for many cases, I didn't use it because the FAQ there: #22861
According to MDN, the So, for advanced users who could configure their system correctly, I think it is feasible and useful to use Update: to keep simple, maybe hard code |
|
Ok I will craft a PR based on this feedback and then we can continue the discussion there. |
|
I proposed a solution: Refactor AppURL usage #30885 |
Fix #30883 Fix #29591 --------- Co-authored-by: KN4CK3R <[email protected]>
Fix go-gitea#30883 Fix go-gitea#29591 --------- Co-authored-by: KN4CK3R <[email protected]>
Backport #30885 Fix #30883 Fix #29591 Co-authored-by: KN4CK3R <[email protected]>
|
@jessesanford I am using CNOE idpbuilder 0.4.1. I can push and pull images to Gitea from the commandline. However, Argo cannot pull the image from Gitea. Is that the behavior you are fixing with this issue? |
Description
No matter what url the OCI client uses, at first connection Gitea responds with the appropriate www-authenticate header but with an incorrect token url hostname set to the
AppURLinstead of the hostname from the client's request.gitea/routers/api/packages/container/container.go
Line 118 in c660149
This means that we cannot use OCI clients that target protocol://host:port combinations other than the one set in
ROOT_URLas they are redirected by the www-auth header to the protocol://host:port in theROOT_URLvia it's use in the construction of theAppURLvariable.The use case is familiar to anyone who is using gitea to back an on-kubernetes-cluster registry to host images that are pushed from off-cluster but referenced for resources on-cluster.
Very often the ingress protocol://host:port combination that is fronting Gitea as a reverse proxy is inaccessible to on cluster resources or containerized resources (like the kubelet in a kind setup). So those resources will be configured to connect directly to the service bound to the Gitea deployment and the protocol://host:port combination that the kubelet connects to on cluster will not match the one used off cluster.
While much work was done in #19345 to fix the issues with multi-domain support in the gui, it did not make any effort to solve the same problem in the container registry. Therefore #22033 should probably not have been closed.
FWIW the docker registry project uses the request headers to set the authorization response header here I believe https://github.com/distribution/distribution/blob/51a72c2aef976bd55de3a7b8b0120f97b4169476/internal/client/auth/challenge/authchallenge.go#L119-L121 so there is precedent for this behavior.
Gitea Version
1.21.7 built with GNU Make 4.4.1, go1.21.7 : bindata, timetzdata, sqlite, sqlite_unlock_notify
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
KO pushing to Gitea from developer workstation
Pod referencing Gitea Image on Kind cluster that is also hosting Gitea
Git Version
No response
Operating System
No response
How are you running Gitea?
Deployed with Helm on Kind
Relevant containerd config.toml from the Kind node with rewrite to make kubelet pull from the container port rather than the host port of the ingress:
Solution Proof of Concept
As a proof of concept I created a branch over here to test if I could influence the current behavior:
https://github.com/jessesanford/gitea/blob/c2fffabcd5122d258360d4443b6e583fc62e28f1/routers/api/packages/container/container.go#L119-L131
ko pushing container image to
gitea.cnoe.localtest.me:8443from local workstation to on-cluster gitea:Pod events from deploy of pod referencing the container image at
gitea.cnoe.localtest.me:8443pushed by ko:NOTE: the kubelet thinks that it is getting the container from
gitea.cnoe.localtest.me:8443but containerd is pulling it fromgitea.cnoe.localtest.me:443From gitea logs during pull (See the X-Forwarded-Host:[gitea.cnoe.localtest.me] X-Forwarded-Port:[443] in the debug log message)
Database
None
The text was updated successfully, but these errors were encountered: