ROOT_URL dynamically set via HTTP Header (X-Forwarded-Proto and X-Forwarded-Host)

[FootStark]

Feature Description

I have 2 reverse proxies set up to access the same Gitea-backend (one for win-auth and one for basic auth). Authentication by Reverse proxy is working great, my only remaining issue is that the Git-clone-URLs on the Gitea pages contain the wrong link for one of the proxies.

My idea is: Can the ROOT_URL used to create absolute links be set/processed dynamically for a request when a reverse proxy is involved? Industry standard for the headers should be X-Forwarded-Host and X-Forwarded-Proto (obviously only if coming from an allowed address in REVERSE_PROXY_TRUSTED_PROXIES). I think that would be a suitable solution for #6397, too.

I currently have a workaround in place rewriting links in button[data-link] when the page is returned, but it would be nice to have it build in.

Screenshots

No response

[wxiaoguang]

It seems impossible now. The ROOT_URL is also used in many non-http context in my mind.

Update: maybe a possible solution is that we still use ROOT_URL as the default one, and if Gitea receive some headers then it use the new AppURL in the related context.

Some problems should be considered:

1. security, will attacker overwrite the customized AppURL
2. sub-path, like http://domain.com/gitea-subpath/org/team/...

[lunny]

ROOT_URL is a global variable. I don't think it could be changed safely currently.

[DjArt]

Also there similar issues when Gitea was accessed by local IP address in network without internet.

[zeripath]

Also there similar issues when Gitea was accessed by local IP address in network without internet.

We specifically advise that you set the ROOT_URL correctly for this precise reason.

[zeripath]

@FootStark as @lunny says we use the setting.AppURL and setting.AppSubURL as a global constant in multiple places and at multiple levels. It's not the greatest of designs and unfortunately it prevents this kind of feature from being doable except as part of a significant refactor.

---

We'd need to consider a number of things in addition though:

• SSH Clone URLs
• HTTP Clone URLs
• LFS Clone URLs
• API URLs

[FootStark]

@zeripath I do understand the complexities of supporting dynamic AppURL fully, especially if not designed to do so from the beginning. But maybe it would be possible to start implementing this feature step-by-step, by adding a context specific AppURL during request processing and then start using it whereever possible (and making sense). I think that is what @wxiaoguang suggests, too. For AppSubURL: This could be delivered via the proxy and HTTP header, too.
I think for a more complete implementation, a default URL would be necessary per user (e.g. for links in notification emails).

In terms of security I do not see a big problem, as the behaviour can be limited to trusted proxies (just as it is for reverse proxy auth).

A completely different approach could be to support a second gitea instance running on the same db / repo, but with a different ROOT_URL. Yet, I believe that would be even harder to implement in terms of process synchronization.

[wxiaoguang]

The root case is #19345 , it should be fixed by relative URLs, instead of introducing an extra header.