Vault-Sync: LFS-Upload scheitert hinter Reverse Proxy (doppelter Authorization-Header) #243
Labels
No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
iris/Iris#243
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Befund
Der Vault-Abgleich lädt Anhänge (Git-LFS) hinter dem Reverse Proxy (nginx/openresty) nicht hoch. Beim Verbinden mit einem neuen Repo bricht der Push mit
ab. Betroffen sind Objekte jeder Größe (22 KB bis 60 MB);
ship/Abgleich zeigen nur diesen Text, Forgejo selbst protokolliert keinen Fehler.Ursache (gemessen)
Der Zugang wird per
http.<server>.extraHeader = Authorization: Basic …an git gegeben. git-lfs hängt diesen Header an jede Anfrage an, beim Upload (PUT) zusätzlich denAuthorization-Header aus derbatch-Antwort von Forgejo. Der Upload trägt dann zweiAuthorization:-Zeilen (Trace mitGIT_CURL_VERBOSE=1). Der Reverse Proxy weist das mit 400 ab, bevor Forgejo die Anfrage sieht (Proxy-Log:PUT … 400, kein Ziel; Forgejo-Log: kein PUT).Nachgestellt mit dem echten git-lfs gegen dasselbe Repo:
extraHeader(wie die App): 24 von 24 Uploads → 400extraHeader(Zugang über Credential-Helper bzw. URL): 16 parallele Uploads, 413 MB, 39 MB/s, alle 200Die 544 KB/s in der App sind sehr wahrscheinlich Wiederholungen der fehlgeschlagenen Uploads (nicht eigens gemessen).
Fix
Zugang nicht mehr als
extraHeader, sondern als Credential-Helper für genau diesen Server (Token nur in der Umgebung des git-Prozesses, nie in.git/config, nie in der Prozessliste). Diebatch-Antwort liefert dann den einzigenAuthorization-Header des Uploads.Prüfen
Authorization-Header an..git/config.Der Linux-Server nutzt dasselbe Muster (
_basic_auth_env) und bekommt ein eigenes Issue (iris/iris-linux-server).PR #244 gemergt: fix(vault-sync): LFS-Upload ohne doppelten Authorization-Header (#243)
#244
Commits:
Stand (2026-10-29)
Befund: Der LFS-Upload scheiterte hinter dem Reverse Proxy (nginx/openresty) mit
LFS: Client errorbei jedem Objekt. Ursache:http.<Server>.extraHeaderund derAuthorization-Header derbatch-Antwort ergeben zweiAuthorization:-Zeilen im PUT; der Proxy antwortet 400, Forgejo sieht nichts.Geändert:
VaultSyncCredentials.authEnvironmentgibt den Zugang als Credential-Helper nur für diesen Server (credential.<scope>.helper, Token inIRIS_VAULT_TOKENder Prozess-Umgebung). Das leerecredential.helper(kein Keychain) kommt jetzt ebenfalls über die Umgebung statt über-c, sonst würde es den Helper löschen. Tests angepasst und ergänzt (keinextraHeader, Token nicht im Helper-Text). Dokumentation: Wire-Protokoll, Abschnitt Zugangsdaten.Geprüft:
test-vault-sync-core.sh(274 Prüfungen) undtest-forgejo-core.sh(41) grün. Mit dem echten git-lfs und genau dieser Umgebung gegen den echten Proxy: mitextraHeader24 von 24 Uploads → 400, mit Credential-Helper 24 von 24 → 200 (572 MB, 62 MB/s).Nicht geprüft: Die gebaute App selbst (Xcode-Build) und ein kompletter Verbinden-Lauf mit dem 29-GB-Vault. Die Server mit Iris-CA (
sslCAInfo) sind nur durch die Tests abgedeckt.Offen: Gegenstück iris/iris-linux-server#128 (gleicher Fehler). Die 544 KB/s sind vermutlich Wiederholungen der fehlgeschlagenen Uploads, nicht eigens gemessen. Die SolidCraft-Sperrdatei (
.~*.sc.lock) im Export geteilter Chats ist ein eigener, noch nicht behobener Fehler.PR #133 gemergt: docs(wire): Zugang per Credential-Helper statt extraHeader (iris/Iris#243)
alf/2ndbrain#133
Commits: