Username in HTTPS clone URL #1135

Originally created by @silverwind on GitHub (Oct 9, 2017).

Two ideas regarding HTTP(s) clone URLs:

Include the username in the URL when a login is required. E.g. https://user@hostname/anotheruser/project. This is important on older git clients (1.x) which do not prompt for a username when a 403 response is received (They just spew the error and exit). On newer git clients, this saves one from typing the username.

2) Obtain the protocol via JS from location.protocol instead of the current hard-coded https://. This is useful for cases when gitea is reachable via HTTP but not HTTPS. Another, possibly less reliable option could be to check a X-Forwarded-Proto header on the server.

Originally created by @silverwind on GitHub (Oct 9, 2017). Two ideas regarding HTTP(s) clone URLs: 1) Include the username in the URL when a login is required. E.g. `https://user@hostname/anotheruser/project`. This is important on older git clients (1.x) which do not prompt for a username when a 403 response is received (They just spew the error and exit). On newer git clients, this saves one from typing the username. ~~2) Obtain the protocol via JS from `location.protocol` instead of the current hard-coded `https://`. This is useful for cases when gitea is reachable via HTTP but not HTTPS. Another, possibly less reliable option could be to check a `X-Forwarded-Proto` header on the server.~~

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 03:49:41 -06:00

GiteaMirror closed this issue

GiteaMirror commented

@Morlinest commented on GitHub (Oct 9, 2017):

About second point. Protocol is not hardcoded. setting.AppURL is used.

@Morlinest commented on GitHub (Oct 9, 2017): About second point. Protocol is not hardcoded. `setting.AppURL` is used.

GiteaMirror commented

@silverwind commented on GitHub (Oct 9, 2017):

About second point. Protocol is not hardcoded. setting.AppURL is used.

Right, but that won't cover the case when one wants to offer both HTTP and HTTPS. It's a rare case but it could be nicely covered by just taking the current protocol from the browser via JS, with a fallback to the AppURL setting when JS is disabled.

@silverwind commented on GitHub (Oct 9, 2017): > About second point. Protocol is not hardcoded. setting.AppURL is used. Right, but that won't cover the case when one wants to offer both HTTP and HTTPS. It's a rare case but it could be nicely covered by just taking the current protocol from the browser via JS, with a fallback to the AppURL setting when JS is disabled.

GiteaMirror commented

@Morlinest commented on GitHub (Oct 9, 2017):

When do you use both at the same time? If you access gitea web on http:// it will be http, if on https:// it will be https. As protocol is part of ApiURL we would need to implement it other way for everything and in setup we would have to include something like "allowed protocols".

@Morlinest commented on GitHub (Oct 9, 2017): When do you use both at the same time? If you access gitea web on `http://` it will be `http`, if on `https://` it will be `https`. As protocol is part of `ApiURL` we would need to implement it other way for everything and in setup we would have to include something like "allowed protocols".

GiteaMirror commented

@Morlinest commented on GitHub (Oct 9, 2017):

In other words, if gitea is reachable via HTTP, it will be http and if via HTTPS it will be https. Maybe you want to be able to reach gitea on both ports, not when:

when gitea is reachable via HTTP but not HTTPS

Right?

@Morlinest commented on GitHub (Oct 9, 2017): In other words, if gitea is reachable via HTTP, it will be `http` and if via HTTPS it will be `https`. Maybe you want to be able to reach gitea on both ports, not when: > when gitea is reachable via HTTP but not HTTPS Right?

GiteaMirror commented

@lafriks commented on GitHub (Oct 10, 2017):

There are people using gitea without javascript

@lafriks commented on GitHub (Oct 10, 2017): There are people using gitea without javascript

GiteaMirror commented

@daviian commented on GitHub (Oct 10, 2017):

Why would someone prefer HTTP if HTTPS is available?
If HTTPS is not available http:// is shown anyway.

@daviian commented on GitHub (Oct 10, 2017): Why would someone prefer HTTP if HTTPS is available? If HTTPS is not available http:// is shown anyway.

GiteaMirror commented

@silverwind commented on GitHub (Oct 12, 2017):

Why would someone prefer HTTP if HTTPS is available?

They probably shouldn't from a security standpoint. If security is of no concern, HTTP generally performs better than HTTPS because of less protocol overhead. Also, I once had case where I could reach HTTP but not HTTPS because of a broken firewall that wasn't under my control. But generally, I agree, HTTPS should be preferred and people who know what they're doing will just change the URL manually after copying it.

Any objections to my first suggestion of including the username in the HTTPS clone URL? I can't think of a downside to it. Less typing and more compatible with git 1.x.

@silverwind commented on GitHub (Oct 12, 2017): > Why would someone prefer HTTP if HTTPS is available? They probably shouldn't from a security standpoint. If security is of no concern, HTTP generally performs better than HTTPS because of less protocol overhead. Also, I once had case where I could reach HTTP but not HTTPS because of a broken firewall that wasn't under my control. But generally, I agree, HTTPS should be preferred and people who know what they're doing will just change the URL manually after copying it. Any objections to my first suggestion of including the username in the HTTPS clone URL? I can't think of a downside to it. Less typing and more compatible with git 1.x.

GiteaMirror commented

@lafriks commented on GitHub (Oct 12, 2017):

If it has no compatibility issues than I have nothing against first suggestion but that can be done only for private repositories

@lafriks commented on GitHub (Oct 12, 2017): If it has no compatibility issues than I have nothing against first suggestion but that can be done **only for private** repositories

GiteaMirror commented

@silverwind commented on GitHub (Oct 12, 2017):

only for private repositories

I have non-private repositories that also require authentication. IIRC, the REQUIRE_SIGNIN_VIEW allows this configuration. I think the check whether to include the username could be if (repo.private || REQUIRE_SIGNIN_VIEW) (pseudocode).

@silverwind commented on GitHub (Oct 12, 2017): > only for private repositories I have non-private repositories that also require authentication. IIRC, the [`REQUIRE_SIGNIN_VIEW`](https://github.com/go-gitea/gitea/blob/a4cd4616c6f8524f8eb79d6184e855b3a8164130/conf/app.ini#L256) allows this configuration. I think the check whether to include the username could be `if (repo.private || REQUIRE_SIGNIN_VIEW)` (pseudocode).

GiteaMirror commented

@Morlinest commented on GitHub (Oct 12, 2017):

You can add username only if user is logged. This feature can be added, but not as default.

@Morlinest commented on GitHub (Oct 12, 2017): You can add username only if user is logged. This feature can be added, but not as default.

GiteaMirror commented

@silverwind commented on GitHub (Oct 12, 2017):

Yes, of course, that would be anther condition, thought I doubt any of the two above conditions can be true when the user is not logged in.

@silverwind commented on GitHub (Oct 12, 2017): Yes, of course, that would be anther condition, thought I doubt any of the two above conditions can be true when the user is not logged in.

GiteaMirror commented

@namadori commented on GitHub (Jul 4, 2018):

Hi there. I'd like the capability of accessing a specific file including credentials in the URL (e.g. https://user:pass@gitea.server.com/org/proj/raw/branch/master/templates/templates.json ).
That would be useful to host configuration files for other applications that does not support authentication.

Is this included in point 1 from @silverwind ? Any updates in that direction from last october?

@namadori commented on GitHub (Jul 4, 2018): Hi there. I'd like the capability of accessing a specific file including credentials in the URL (e.g. https://user:pass@gitea.server.com/org/proj/raw/branch/master/templates/templates.json ). That would be useful to host configuration files for other applications that does not support authentication. Is this included in point 1 from @silverwind ? Any updates in that direction from last october?

GiteaMirror commented

@ptman commented on GitHub (Jul 4, 2018):

@namadori Wouldn't it be possible to have a server (apache, nginx, ...) in front of gitea handle basic auth and then pass the authenticated user to gitea in an HTTP header? REVERSE_PROXY_AUTHENTICATION_USER in config.

@ptman commented on GitHub (Jul 4, 2018): @namadori Wouldn't it be possible to have a server (apache, nginx, ...) in front of gitea handle basic auth and then pass the authenticated user to gitea in an HTTP header? `REVERSE_PROXY_AUTHENTICATION_USER` in config.

GiteaMirror commented

@stale[bot] commented on GitHub (Jan 20, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 20, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

@silverwind commented on GitHub (Feb 20, 2020):

Copying suggestion for username in HTTP(s) clone URL from #10381 here for visibility:

[server]
ROOT_URL = %(PROTOCOL)s://%(USERNAME)@%(DOMAIN)s:%(HTTP_PORT)s/

@silverwind commented on GitHub (Feb 20, 2020): Copying suggestion for username in HTTP(s) clone URL from #10381 here for visibility: ````ini [server] ROOT_URL = %(PROTOCOL)s://%(USERNAME)@%(DOMAIN)s:%(HTTP_PORT)s/

GiteaMirror commented