Ingress

BlueGit staat op de mini-PC en spreekt plain HTTP. TLS, certificaten en de publieke SSH-poort horen bij een ingress op een andere machine. Die machine is de enige die vanaf internet bij de mini-PC mag.

BlueGit bouwt URL's niet uit de binnenkomende Host-kop. De externe website is base_url. De SSH-clone-URL is ssh.public_host en ssh.public_port. listen en ssh.listen zijn alleen de adressen waarop dit proces bindt.

BlueGit

base_url: https://git.timfalken.com
listen: 0.0.0.0:8080
trusted_proxies:
  - 10.0.0.2
ssh:
  enabled: true
  listen: 0.0.0.0:2222
  public_host: git.timfalken.com
  public_port: 22

10.0.0.2 is het adres waarvan de mini-PC de verbinding van de ingress ziet. Een verkeerd adres betekent dat X-Forwarded-For genegeerd wordt. Een te ruime lijst, zoals 0.0.0.0/0, laat elke client zijn adres vervalsen. behind_proxy: true uit een oudere configuratie wordt geweigerd.

In X-Forwarded-For telt de rechtse hop die zelf niet op de lijst staat. Een client die 6.6.6.6 vooraan zet, wint daarmee niet van het adres dat de ingress erachter plakt. Ontbreekt die kop, dan geldt X-Real-IP, maar alleen vanaf een vertrouwde proxy. X-Forwarded-Proto wordt niet gebruikt: de cookie en de OAuth-redirect volgen base_url.

Beperk met de firewall op de mini-PC poort 8080 en 2222 tot de ingress. listen op 0.0.0.0 is bereikbaar voor iedereen die tot het netwerk van de mini-PC kan.

Voorbeeld op de ingress

Caddy doet HTTPS en stuurt door naar de mini-PC. Vervang 10.0.0.5 door het adres van de mini-PC.

git.timfalken.com {
	reverse_proxy 10.0.0.5:8080
}

Caddy zet X-Forwarded-For en X-Forwarded-Proto. Het certificaat komt van Caddy; BlueGit ziet geen TLS.

SSH is geen HTTP. De ingress stuurt de TCP-stroom door, zodat de hostkey van BlueGit is wat de client controleert. Met de Caddy-module caddy-l4:

{
	layer4 {
		:22 {
			route {
				proxy 10.0.0.5:2222
			}
		}
	}
}

Zonder die module kan nginx hetzelfde op de stream-laag:

stream {
	server {
		listen 22;
		proxy_pass 10.0.0.5:2222;
	}
}

De clone-URL op de website is dan git@git.timfalken.com:eigenaar/naam.git (de korte vorm, zoals GitHub). Bij een andere publieke poort wordt het ssh://git@host:poort/eigenaar/naam.git. Op de mini-PC blijft git-SSH op poort 2222 luisteren, naast de SSH van Arch.

Encoded slashes (%2F)

Branchnamen, bestandspaden en patterns van beschermde branches bevatten vaak een /. Clients sturen die slash in het URL-pad soms als %2F, bijvoorbeeld DELETE /api/v1/projects/{owner}/{repo}/repository/branches/feature%2Fx.

Caddy (het voorbeeld hierboven, en de ingress van git.timfalken.com) geeft %2F ongewijzigd door. Dat is op git.timfalken.com gecontroleerd: een verzoek met %2F in het pad komt bij BlueGit uit (een authenticatiefout, geen 404 van de ingress). Daar is geen extra instelling nodig.

Apache weigert %2F standaard met een 404, nog voordat de proxy het verzoek doorstuurt. Zet in de VirtualHost (of de Directory/Location van de site):

AllowEncodedSlashes NoDecode

En als je ProxyPass gebruikt, ook nocanon. Zonder die vlag canoniseert Apache het pad alsnog en blijft %2F stuk:

ProxyPass        / http://10.0.0.5:8080/ nocanon
ProxyPassReverse / http://10.0.0.5:8080/

Vervang 10.0.0.5:8080 door het adres van BlueGit, hetzelfde als in het Caddy-voorbeeld.

BlueGit zelf accepteert zowel een letterlijke slash (feature/x) als %2F in een wildcard-pad. Voor een ingress die %2F niet doorlaat is er een variant zonder slash in het pad:

• DELETE /api/v1/projects/{owner}/{repo}/repository/branches?name=feature/x
• PUT /api/v1/projects/{owner}/{repo}/repository/branches?name=feature/x (nieuwe naam in de JSON-body)
• DELETE /api/v1/projects/{owner}/{repo}/protected_branches?pattern=feature/*
• DELETE /api/v1/projects/{owner}/{repo}/protected_tags?pattern=releases/*
• GET /api/v1/projects/{owner}/{repo}/repository/files?path=docs/INGRESS.md&ref=master

De naam mag bij verwijderen ook in de JSON-body. Tagnamen mogen geen / bevatten; hun pad hoeft dus niet om %2F heen. Vergelijken in de UI gebruikt al queryparameters (/-/compare?from=&to=).