Submodule Reference - wrong url on subdomain #4644

Closed
opened 2025-11-02 05:57:15 -06:00 by GiteaMirror · 7 comments
Owner

Originally created by @Jonas18175 on GitHub (Jan 14, 2020).

Description

I run the git under subdomain https://git.webserver.xyz
I pushed a repo with a submodule to my git and in the webinterface when i click on the reference link in this repository redirect the webserver.xyz instant of http://git.webserver.xyz. I used https on my server. The link is only http:// - had i missconfigured something or is this a bug?

Originally created by @Jonas18175 on GitHub (Jan 14, 2020). - Gitea version (or commit ref): 1.10.1 - Git version: 2.18.1 - Operating system: Linux (Centos 8) - Database (use `[x]`): - [ ] PostgreSQL - [ X] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [X ] No - [ ] Not relevant - Log gist: https://gist.github.com/Jonas18175/f941e4b3cc6ab31bbfc1647d1449fa8e ## Description I run the git under subdomain https://git.webserver.xyz I pushed a repo with a submodule to my git and in the webinterface when i click on the reference link in this repository redirect the webserver.xyz instant of http://git.webserver.xyz. I used https on my server. The link is only http:// - had i missconfigured something or is this a bug?
GiteaMirror added the issue/confirmedtype/bug labels 2025-11-02 05:57:15 -06:00
Author
Owner

@bagasme commented on GitHub (Jan 14, 2020):

@Jonas18175 What about your app.ini?

@bagasme commented on GitHub (Jan 14, 2020): @Jonas18175 What about your `app.ini`?
Author
Owner

@6543 commented on GitHub (Jan 14, 2020):

@Jonas18175 do you use a reverse ssl proxy?
(we need more information how your gitea inctance is setup)

@6543 commented on GitHub (Jan 14, 2020): @Jonas18175 do you use a reverse ssl proxy? (we need more information how your gitea inctance is setup)
Author
Owner

@Jonas18175 commented on GitHub (Jan 15, 2020):

my app.ini:

APP_NAME = Gitea: Git with a cup of tea
RUN_USER = git
RUN_MODE = prod

[security]
INTERNAL_TOKEN = xxx.xxx.xxx
INSTALL_LOCK   = true
SECRET_KEY     = xxx

[database]
DB_TYPE  = mysql
HOST     = 127.0.0.1:3306
NAME     = gitea
USER     = gitea
PASSWD   = xxx
SSL_MODE = disable
PATH     = data/gitea.db

[repository]
ROOT = /srv/git/gitea-repositories

[server]
SSH_DOMAIN       = xxx.tk
DOMAIN           = git.xxx.tk
HTTP_PORT        = 3030
ROOT_URL         = https://git.xxx.tk
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /var/lib/gitea/data/lfs
LFS_JWT_SECRET   = xxx
OFFLINE_MODE     = false

[mailer]
ENABLED = false

[service]
REGISTER_EMAIL_CONFIRM            = false
ENABLE_NOTIFY_MAIL                = false
DISABLE_REGISTRATION              = true
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
ENABLE_CAPTCHA                    = false
REQUIRE_SIGNIN_VIEW               = true
DEFAULT_KEEP_EMAIL_PRIVATE        = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING       = true
NO_REPLY_ADDRESS                  = noreply.example.org

[picture]
DISABLE_GRAVATAR        = false
ENABLE_FEDERATED_AVATAR = true

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = false

[session]
PROVIDER = file

[log]
MODE      = file
LEVEL     = Info
ROOT_PATH = /var/lib/gitea/log

[oauth2]
JWT_SECRET = xxx

yes i used nginx - but some links in some repos and in others not (submodule):

server {
    root /srv/git;
    server_name www.git.xxx.tk git.xxx.tk; 

    index index.html index.php;

    access_log /var/log/nginx/git.access;
    error_log  /var/log/nginx/git.error error;

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/git.xxx.tk/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/git.xxx.tk/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


    location / {
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:3030;
        proxy_redirect off;
    }


}

server {
    listen 80;
    server_name www.git.xxx.tk git.xxx.tk;

    if ($host = www.git.xxx.tk) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = git.xxx.tk) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    return 404; # managed by Certbot
}
@Jonas18175 commented on GitHub (Jan 15, 2020): my app.ini: ``` APP_NAME = Gitea: Git with a cup of tea RUN_USER = git RUN_MODE = prod [security] INTERNAL_TOKEN = xxx.xxx.xxx INSTALL_LOCK = true SECRET_KEY = xxx [database] DB_TYPE = mysql HOST = 127.0.0.1:3306 NAME = gitea USER = gitea PASSWD = xxx SSL_MODE = disable PATH = data/gitea.db [repository] ROOT = /srv/git/gitea-repositories [server] SSH_DOMAIN = xxx.tk DOMAIN = git.xxx.tk HTTP_PORT = 3030 ROOT_URL = https://git.xxx.tk DISABLE_SSH = false SSH_PORT = 22 LFS_START_SERVER = true LFS_CONTENT_PATH = /var/lib/gitea/data/lfs LFS_JWT_SECRET = xxx OFFLINE_MODE = false [mailer] ENABLED = false [service] REGISTER_EMAIL_CONFIRM = false ENABLE_NOTIFY_MAIL = false DISABLE_REGISTRATION = true ALLOW_ONLY_EXTERNAL_REGISTRATION = false ENABLE_CAPTCHA = false REQUIRE_SIGNIN_VIEW = true DEFAULT_KEEP_EMAIL_PRIVATE = false DEFAULT_ALLOW_CREATE_ORGANIZATION = true DEFAULT_ENABLE_TIMETRACKING = true NO_REPLY_ADDRESS = noreply.example.org [picture] DISABLE_GRAVATAR = false ENABLE_FEDERATED_AVATAR = true [openid] ENABLE_OPENID_SIGNIN = true ENABLE_OPENID_SIGNUP = false [session] PROVIDER = file [log] MODE = file LEVEL = Info ROOT_PATH = /var/lib/gitea/log [oauth2] JWT_SECRET = xxx ``` yes i used nginx - but some links in some repos and in others not (submodule): ``` server { root /srv/git; server_name www.git.xxx.tk git.xxx.tk; index index.html index.php; access_log /var/log/nginx/git.access; error_log /var/log/nginx/git.error error; listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/git.xxx.tk/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/git.xxx.tk/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot location / { proxy_set_header Host $host; proxy_pass http://127.0.0.1:3030; proxy_redirect off; } } server { listen 80; server_name www.git.xxx.tk git.xxx.tk; if ($host = www.git.xxx.tk) { return 301 https://$host$request_uri; } # managed by Certbot if ($host = git.xxx.tk) { return 301 https://$host$request_uri; } # managed by Certbot return 404; # managed by Certbot } ```
Author
Owner

@stale[bot] commented on GitHub (Mar 15, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 15, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
Author
Owner

@stale[bot] commented on GitHub (Mar 29, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Mar 29, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.
Author
Owner

@zeripath commented on GitHub (Mar 29, 2020):

Sorry I don't think anyone has had any time to look into this - however, I can see how this could happen.

The trouble is in general it's very hard (I think impossible) to definitively convert an arbitrary submodule to a http link however, we can and should be doing it correctly for things that point to the same gitea instance.

A general solution would likely involve the repository having some set-up whereby it has a mapping from submodule to its http address.

@zeripath commented on GitHub (Mar 29, 2020): Sorry I don't think anyone has had any time to look into this - however, I can see how this could happen. The trouble is in general it's very hard (I think impossible) to definitively convert an arbitrary submodule to a http link however, we can and should be doing it correctly for things that point to the same gitea instance. A general solution would likely involve the repository having some set-up whereby it has a mapping from submodule to its http address.
Author
Owner

@mrsdizzie commented on GitHub (Mar 29, 2020):

This should work, what is in the [submodule] section of the git repo?

@mrsdizzie commented on GitHub (Mar 29, 2020): This should work, what is in the [submodule] section of the git repo?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4644