Skip to content

[JS BUG] repo page shows incorrect clone url under different domain names #29084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
darkclip opened this issue Feb 7, 2024 · 2 comments · Fixed by #29085
Closed

[JS BUG] repo page shows incorrect clone url under different domain names #29084

darkclip opened this issue Feb 7, 2024 · 2 comments · Fixed by #29085
Labels

Comments

@darkclip
Copy link

darkclip commented Feb 7, 2024

Description

I deployed gitea instance in a vm that can be accessed from both inside and outside networks.
So, I have different domain names and different ports under different network env.
In gitea config file, i set the ROOR_URL to one domain name with a port append to it, visit the other domain using standard port.
for example: ROOR_URL = https://git.aaa.com:8443/ and visit https://git.bbb.com/
however, the clone button's HTTPS url shows: https://git.bbb.com:8443/owner/repo.git

I search through source code of gitea, found that inside
templates/repo/clone_script.tmp and web_src/js/webcomponents/GiteaOriginUrl.js
have the following to replace the app URL with the visiting protocol and host:

const url = new URL(link);
url.protocol = window.location.protocol;
url.host = window.location.host;
link = url.toString();

however, that doesn't set the url.port attribute, resulting incorrect clone URL.

Gitea Version

1.21.5

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

docker

Database

None

@silverwind
Copy link
Member

silverwind commented Feb 7, 2024

Hmm yes this looks like a edge case with empty port where it's not being set.

> const url = new URL("https://git.aaa.com:8443/owner/repo.git", "https://git.bbb.com")
undefined
> url.host = "git.bbb.com"; url.toString()
'https://git.bbb.com:8443/owner/repo.git'
> url.host = "git.bbb.com:443"; url.toString()
'https://git.bbb.com/owner/repo.git'

silverwind added a commit to silverwind/gitea that referenced this issue Feb 7, 2024
When setting `url.host` on a URL object with no port specified, the
resulting URL's protocol will not change. Workaround this quirk in the
URL standard by explicitely setting port for the http and https
protocols.

Extracted the logic to a function for the purpose of testing it.
Initially I wanted to have the function in utils.js, but it turns out
esbuild can not treeshake the unused functions which would result in the
webcomponents chunk having all of utils.js inlined.

Fixes: go-gitea#29084
silverwind added a commit to silverwind/gitea that referenced this issue Feb 7, 2024
When setting `url.host` on a URL object with no port specified, the
resulting URL's protocol will not change. Workaround this quirk in the
URL standard by explicitely setting port for the http and https
protocols.

Extracted the logic to a function for the purpose of testing it.
Initially I wanted to have the function in utils.js, but it turns out
esbuild can not treeshake the unused functions which would result in the
webcomponents chunk having all of utils.js inlined.

Fixes: go-gitea#29084
silverwind added a commit to silverwind/gitea that referenced this issue Feb 7, 2024
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: go-gitea#29084
lunny pushed a commit that referenced this issue Feb 8, 2024
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: #29084
GiteaBot pushed a commit to GiteaBot/gitea that referenced this issue Feb 8, 2024
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: go-gitea#29084
lunny pushed a commit that referenced this issue Feb 8, 2024
Backport #29085 by @silverwind

When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: #29084

Co-authored-by: silverwind <[email protected]>
DennisRasey pushed a commit to DennisRasey/forgejo that referenced this issue Feb 10, 2024
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: go-gitea/gitea#29084
(cherry picked from commit b6bf804)
DennisRasey pushed a commit to DennisRasey/forgejo that referenced this issue Feb 14, 2024
Backport #29085 by @silverwind

When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: go-gitea/gitea#29084

Co-authored-by: silverwind <[email protected]>
(cherry picked from commit fb7f28e)
silverwind added a commit to silverwind/gitea that referenced this issue Feb 20, 2024
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.

Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.

Fixes: go-gitea#29084
Copy link

Automatically locked because of our CONTRIBUTING guidelines

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants