fix(portal): identity header deleted-after-set → portal showed no data - #183
Merged
Merged
Conversation
…wed no data The portal landing page rendered but every widget said 'Gerätedaten nicht verfügbar': portalIdentity never saw X-GC-Portal-Peer-IP, so every /api/v1/portal/* call returned 'unidentified'. Root cause: the portal gate route's reverse_proxy set the header AND also deleted it in the same headers.request block. Caddy applies `delete` AFTER `set`, so the just-set value was nuked and Node received nothing. Empirically confirmed against the live Caddy admin API (delete+set -> header undefined; set-only -> trusted value, and it still overwrites a client-forged copy, so forgery protection is intact). Fix: SET only on the portal gate route (set already replaces any client-supplied copy). The management vhost keeps delete-only (correct — it just strips the header). Latent since portal Phase 1; only surfaced now that the portal is actually reachable via a public host. Adds a regression test asserting the gate route SETs the header and does NOT also delete it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
Das VPN-Landing-Portal (
home.domaincaster.com) rendert die Seite, aber alle Widgets (Gerät, Traffic, Dienste) zeigen „Gerätedaten nicht verfügbar".Root Cause (live diagnostiziert)
Der Request kommt intern korrekt an (
remote_ip=10.8.0.5, 200), aberportalIdentityetabliert nie eine Peer-Identität → jeder/api/v1/portal/*-Call liefertunidentified.Ursache: Die Portal-Gate-Route setzte den Identitäts-Header
X-GC-Portal-Peer-IPUND löschte ihn im selbenheaders.request-Block (delete+set). Caddy wendetdeleteNACHsetan → der gerade gesetzte Wert wird wieder entfernt → Node bekommt den Header nie → keine Identität.Empirisch gegen die Live-Caddy-Admin-API bestätigt:
delete+setauf demselben Header → Upstream empfängtundefined.setallein → Upstream empfängt den vertrauenswürdigen Wert und überschreibt einen client-gefälschten Header (Forgery-Schutz bleibt intakt).Fix
Auf der Portal-Gate-Route nur noch
set(keindelete).setersetzt jeden client-gelieferten Wert mit{http.request.remote.host}(echte TCP-Quelle) → sicher. Der Management-vhost behältdelete-only (korrekt — er strippt den Header nur).Latenter Bug seit Portal-Phase-1 — erst sichtbar, seit das Portal über einen öffentlichen Host real genutzt wird.
Tests
Neuer Regressionstest: Gate-Route SETZT den Header und löscht ihn NICHT.
portal_dns_caddy6/6, volle Portal-Suite 60/60 grün.🤖 Generated with Claude Code