gitea: Multi-domain support, ROOT_URL problem, use relative URLs in templates instead of absolute URLs

Most problems in this issue have been addressed by #21986, so I think it’s good to:

1. Remove most ROOT_URL error messages on the page, only show it to site admin.
2. Close this issue
3. Open a new issue to follow remaining and new problems.

Now the “Multidomain support” is about 50%-70%.

• A correct main domain (ROOT_URL) is still necessary, because Gitea sends mails/notifications with no knowledge of “current domain”
• There are still incorrect usages of AppURL(ROOT_URL) in code, which should be cleaned one by one in the future.

+1, relative URLs may even enable use cases like running on multiple domains. Thought IIRC, ROOT_URL still needs to stay in the config because sometimes absolute URLs need to be built, like for PR link when pushing via SSH. But it’s good nonetheless to remove dependencies on ROOT_URL where possible.

Thank you very much, i found the PR after posting the comment.

.js-global-error {
    display: none !important;
}

<link rel="stylesheet" href="/assets/css/header.css">

edited by wxiaoguang: ⚠️ please see the WARNING in other comments, do not do so ⚠️

So I think we need an ALLOWED_ROOT_URLS, which could have a glob matching. When a request to a disallowed root url, Gitea should return 404 or redirect to 404.

I found it’s difficult to get the right root url in the backend because maybe there are some reverse proxies. So it’s only done by frontend.

But ROOT_URL cannot be removed because some places need that. i.e. When sending an email, the link needs an absolute url. We can reuse ROOT_URL as the default value of that.

First time I have tried gitea and find it surprising that there is no mention of this at all on the docs. The docs give an impression that the user can set the environment, but this is incorrect. I’ll give a subset of examples, there are several more:

Documentation: Install with docker To bind the integrated OpenSSH daemon and the webserver on a different port, adjust the port section. It’s common to just change the host port and **keep the ports within the container like they are**.

Gitea explicitly overrides a lot of headers and links. The advice to differentiate the environment e.g. inside and outside a container, only makes sense if the application offers the configuration feature. E.g. docker mapping to port 3000, instead of 80 or 443, will make you really wonder what the source of the fault is then links dont work. At least by mimic’ing the env on standard ports, some subset will resolve properly.

Documentation: Managing deployments with environemt variables In addition to the environment variables above, **any settings in app.ini can be set or overridden with an environment variable** of the form: GITEA__SECTION_NAME__KEY_NAME.

This is pure misinformation as the application never properly supported configuration in this manner. The docs seems to be describing a roadmap of how it should end up to be, rather than the factual.

Documentation: Recommended server configuration NOTE: Many of the following directories can be configured using [Environment Variables](https://docs.gitea.io/en-us/environment-variables/) as well! Of note, configuring GITEA_WORK_DIR will tell Gitea where to base its working directory, as well as ease installation.

and

Documentation: reverse proxies

No, the application will override the proxy headers e.g. all of the repository links. This will break your env if you rely on the proxy with redirects URI also.

If you follow the docs you will end up with a broken system going in a loop until you find the source of the problem. Would it be possible to mention that this doesnt work on the docs? 😃

⚠️ WARNING about ignoring the “inconsistent domain” message

To be clear : if you see the error message but you ignore it, you will run into problem.

Please DO NOT do so before Gitea has a clear solution, unless that you are very very sure about what you are doing and you can resolve all your users’ problems. That’s why I didn’t make an option or provide any detail steps for hiding it.

I will hide some unrelated comments and edit to put some warnings in some comments, because if many users ignore the warning, there will be a lot of duplicate issues here reporting that “something doesn’t work” (it happened before).

For example, user who log in https://git/ can not do preview if the ROOT_URL is https://git.domain/. They can not do inline PR comment either, there could be more similar problems. You can only ignore the error message if you are sure your users won’t use these affected features on different domains.

If you are sure you can ignore the warning, there is a bypass method to hide the warning, see the FAQ in #18971 .

There is a specialized CSS class “js-global-error” for the error message, then end users still have a chance to hide these error messages by customized CSS styles.

edited: ⚠️ please see the WARNING in other comments, do not do so ⚠️

We need a new global variable ROOT_URL_PATH, it could be / or sub path like /gitea. For repository, we could have a new HTMLURLPath