acceptedPushTransports limiting to HTTPS does not work when behind proxy.

[urkle]

I have gitblit configured behind a proxy server (traefik) which is providing HTTPS (so gitblit access is HTTP behind the proxy)

However when I configure this
acceptedPushTransports=SSH HTTPS

It does not allow pushes as it does not detect that we are in-fact really doing HTTPS.

Is there perhaps some header that needs to be set to make gitblit happy? (I'm using the docker container image on kubernetes)

In the end I had to change it to
acceptedPushTransports=SSH HTTPS HTTP

This was in an attempt to get LFS working correctly, as LFS wont work over SSH (and no clue how to force JUST LFS over https)

Now, further "oddities" is that now that I have it configured this way, it will periodically attempt to push to http:// (which of course is redirected to https by traefik), however now there are two entries stored in my keychain (one for http and one for https)

[flaix]

But, you are not using HTTPS. From Gitblit's viewpoint you are using HTTP. Because that is the connector it has open and is accepting connections from the proxy on. So I am not sure what you mean when you say that you "are in-fact really doing HTTPS".

As for the second part, that seems to be a question regarding whatever Git client you are using, and not Gitblit itself.

[urkle]

@flaix I can only make connections to Gitblit via my load balancer which is exposing only HTTPS. It itself is communication (internally only) to the HTTP port on gitblit. e.g. there should be no reason for met o setup SSL on that internal communication channel as well as that is in a secured setup (in my case it is in kubernetes).

Other applications I have used (or built) handle this by checking a X-Forwarded-Proto header to determine this. ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto )

[flaix]

Apparently I am totally missing what your actual problem is. What is the original problem you are dealing with, that makes you feel you have to enable HTTPS?

[urkle]

I wanted to have my gitblit configured with just SSH & HTTPS transports ( acceptedPushTransports=SSH HTTPS

But, that doesn't work if only the load balancer is providing SSL, as GitBlit does not check X-Forwarded-Proto headers to recognize that the client is indeed utilizing HTTPS. Gitblit assumes it is HTTP, and rejects the request.

[flaix]

Okay, let me ask differently, what is the problem with configuring SSH and HTTP as accepted transports? What is the effect of that, that you want to avoid?

[urkle]

It is unexpected errors when you have it configured as SSH + HTTPS and it doesn't work. (with no clear indication that is why). I spent quite a while fighting with things trying to figure out why it wasn't working.

Further, being able to properly set it as SSH+HTTPS adds extra protection against misconfigurations.

Honestly, if you could point me to where about in the code the change would need to be made to support this I can make a PR to add the handling of the X-Fowarded-Proto header.

[flaix]

I probably can, I will have to look into it.
I can also check my setups, because I always have it running behind a nginx reverse proxy which handles the TLS. I did not have any unexpected errors with that. Could you be more specific about what errors these are exactly.

[urkle]

I was getting constant authentication errors as the GIT client was being refused to push content up as gitblit thought it was using http vs https (as I had restricted my acceptable push protocols). I had not noticed this before as I always use SSH to push content, but due to gitblit not implementing LFS over SSH I had to switch to HTTPS for one of my projects that I was switching to utilize LFS on.

I can change my configuration tomorrow and retest and dump client errors here.

[flaix]

Hmm, true, I have always only pushed via SSH. I am not sure that I ever tried HTTPS. I would have to test that.

[flaix]

I can not reproduce this.
I have set up a new Gitblit server behind a nginx reverse proxy. The nginx proxy uses TLS towards the client. Gitblit only uses HTTP and the proxy uses HTTP towards the Gitblit instance.

server {
	listen 443 ssl default_server;
	listen [::]:443 ssl default_server;

	include snippets/snakeoil.conf;
	server_name _;

	location / {
		proxy_pass http://127.0.0.1:8080;
	}
}

git.daemonPort = 0
git.acceptedPushTransports = HTTP SSH
server.httpPort = 8080
server.httpsPort = 0
web.canonicalUrl = https://10.2.3.4/

This works for me. I can access the web interface, I can clone via HTTPS and SSH and I can push via HTTPS and SSH.

flaix@mints:~/Devel$ git -c http.sslVerify=false clone https://flaix@10.2.3.4/r/test1.git
Cloning into 'test1'...
remote: Counting objects: 16, done
remote: Finding sources: 100% (16/16)
remote: Getting sizes: 100% (10/10)
remote: Compressing objects: 100% (278/278)
remote: Total 16 (delta 2), reused 12 (delta 1)
Unpacking objects: 100% (16/16), 1.49 KiB | 763.00 KiB/s, done.
flaix@mints:~/Devel$ cd test1
flaix@mints:~/Devel/test1$ echo "Hello" > world
flaix@mints:~/Devel/test1$ git add world
flaix@mints:~/Devel/test1$ git commit -m "Hello world"
[master 7117521] Hello world
 1 file changed, 1 insertion(+)
 create mode 100644 world
flaix@mints:~/Devel/test1$ git -c http.sslVerify=false push
Password for 'https://flaix@10.2.3.4': 
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 2 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 316 bytes | 316.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Updating references: 100% (1/1)
To https://10.2.3.4/r/test1.git
   d8d58c3..7117521  master -> master

If you are still having trouble with this, then you will need to post more precise error information. I have never used traeffic so I cannot say if that does anything special which would result in errors. But in general the setup behind a reverse proxy doing the HTTPS and connecting via HTTP to Gitblit is known to work.