In reverse proxy setup the "Repositories" pane illegitimately has links with HTTP_PORT but all other links do not #8509

New Issue

GiteaMirror · 2025-11-02T08:09:12-06:00

GiteaMirror commented

2025-11-02 08:09:12 -06:00

Originally created by @gavinbeatty on GitHub (Feb 5, 2022).

Gitea Version

Gitea version 1.16.0 built with GNU Make 4.1, go1.17.6 : bindata, sqlite, sqlite_unlock_notify

Git Version

git version 2.20.1

Operating System

Debian GNU/Linux 10 (buster)

How are you running Gitea?

Installed from https://dl.gitea.io/gitea/ download
Using reverse proxy nginx on standard ports, redirecting subdomain to gitea listening on 127.0.0.1:3000

Relevant part of gitea.init:

[server]
PROTOCOL = http
DOMAIN = redacted.example.com
ROOT_URL = %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/
STATIC_URL_PREFIX =
HTTP_ADDR = 127.0.0.1
HTTP_PORT = 3000
REDIRECT_OTHER_PORT = false
PORT_TO_REDIRECT = 3080

nginx is nothing special, location / using proxy_pass http://localhost:3000. No issues there.

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

After login, almost all listed have correct URLs like https://redacted.example.com/user/repo. All links are correctly using https and no explicit port, e.g., https://redacted.example.com/explore/repos, etc..

The problem is that the URLs listed in the Repositories pane on the right hand side have URLs like http://redacted.example.com:3000/user/repo. Note the http and explicit port.

Also important is that in the Explore page, the URLs are correctly https and without explicit port again.

This is a problem because gitea is not listening on an exposed interface on port 3000 -- all those :3000 URLs are inaccessible.

This seems to be a bug in the page generation logic for the main/home page after login, because the issue presents itself only in that one page and in fact only in that one pane within the page. I don't know anything about the internals of gitea, but in a casual inspection of a text dump of the sqlite gitea.db, I didn't find any explicit mention of 3000.

Screenshots

Originally created by @gavinbeatty on GitHub (Feb 5, 2022). ### Gitea Version Gitea version 1.16.0 built with GNU Make 4.1, go1.17.6 : bindata, sqlite, sqlite_unlock_notify ### Git Version git version 2.20.1 ### Operating System Debian GNU/Linux 10 (buster) ### How are you running Gitea? * Installed from https://dl.gitea.io/gitea/ download * Using reverse proxy nginx on standard ports, redirecting subdomain to gitea listening on 127.0.0.1:3000 Relevant part of gitea.init: ```ini [server] PROTOCOL = http DOMAIN = redacted.example.com ROOT_URL = %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/ STATIC_URL_PREFIX = HTTP_ADDR = 127.0.0.1 HTTP_PORT = 3000 REDIRECT_OTHER_PORT = false PORT_TO_REDIRECT = 3080 ``` nginx is nothing special, location / using proxy_pass http://localhost:3000. No issues there. ### Database SQLite ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description After login, almost all listed have correct URLs like https://redacted.example.com/user/repo. All links are correctly using https and no explicit port, e.g., https://redacted.example.com/explore/repos, etc.. The problem is that the URLs listed in the Repositories pane on the right hand side have URLs like http://redacted.example.com:3000/user/repo. Note the http and explicit port. Also important is that in the Explore page, the URLs are correctly https and without explicit port again. This is a problem because gitea is not listening on an exposed interface on port 3000 -- all those :3000 URLs are inaccessible. This seems to be a bug in the page generation logic for the main/home page after login, because the issue presents itself only in that one page and in fact only in that one pane within the page. I don't know anything about the internals of gitea, but in a casual inspection of a text dump of the sqlite gitea.db, I didn't find any explicit mention of 3000. ### Screenshots ![Screenshot 2022-02-05 at 20-01-04 Gitea censor](https://user-images.githubusercontent.com/88261/152657181-4b0fdd15-f030-4f1e-9fde-ce1d002dd402.png)

GiteaMirror closed this issue

2025-11-02 08:09:12 -06:00

GiteaMirror commented

2025-11-02 08:09:13 -06:00

@gavinbeatty commented on GitHub (Feb 5, 2022):

I cannot confirm, but I believe this issue was not present on 1.15.10 and 1.15.11. I cannot be sure as I used these versions for a very short period of time and did not often use the web interface during that time.

@gavinbeatty commented on GitHub (Feb 5, 2022): I cannot confirm, but I believe this issue was not present on 1.15.10 and 1.15.11. I cannot be sure as I used these versions for a very short period of time and did not often use the web interface during that time.

GiteaMirror commented

2025-11-02 08:09:13 -06:00

@wxiaoguang commented on GitHub (Feb 6, 2022):

Document says: set ROOT_URL to your real public URL.

@wxiaoguang commented on GitHub (Feb 6, 2022): Document says: set ROOT_URL to your real public URL.

GiteaMirror commented

2025-11-02 08:09:13 -06:00

@gavinbeatty commented on GitHub (Feb 6, 2022):

Thanks, worked, and apologies for not reading docs more carefully. I tried just removing the :%(HTTP_PORT)s portion but must have made a mistake, or the lack of https also caused an issue.

I was also led astray by the fact that only a tiny subset of URLs were inaccurate. Thanks again.

@gavinbeatty commented on GitHub (Feb 6, 2022): Thanks, worked, and apologies for not reading docs more carefully. I tried just removing the `:%(HTTP_PORT)s` portion but must have made a mistake, or the lack of https also caused an issue. I was also led astray by the fact that only a tiny subset of URLs were inaccurate. Thanks again.

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#8509