fix(frontend): forward X-Pangolin-Token zum Backend (Browser-User 503-Fix)#130
Conversation
…-Fix) Pangolin Resources koennen via Header-Auth einen statischen Trust-Token als Custom Upstream-Header injecten (X-Pangolin-Token). Das Backend akzeptiert ihn ueber den sso_trust_header Mechanismus als SSO-equivalentes Signal. Bisher hat WithAuthFrom in client.go diesen Header NICHT an Backend-Calls weitergereicht, sondern nur X-Pangolin-User, X-Label-Hub-Key und Authorization. Konsequenz: Browser-User ohne aktive Pangolin-SSO-Session konnten KEINE UI-Route nutzen die Backend-Daten holt - Dashboard (/), /printers, /jobs, /templates, /admin/* gaben alle 503 zurueck. Nur /healthz funktionierte weil der nicht zum Backend ruft. Fix: X-Pangolin-Token zur Forwarding-Liste hinzugefuegt. Test: TestWithAuthFromForwardsPangolinTokenHeader prueft via httptest-Backend dass der Header beim Backend ankommt. Test war RED vor Fix, GREEN danach. Live-Verifikation (vor Fix): - /healthz: 200 OK - /: 503 (Frontend forwarded X-Pangolin-Token nicht) - Direkter Backend-Call mit X-Pangolin-User: 200 OK + JSON - Direkter Frontend-Call mit X-Pangolin-User: 200 OK + UI Refs Issue-Tracker (kein eigenes Issue, akut entdeckt 2026-06-23)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #130 +/- ##
==========================================
+ Coverage 87.71% 87.75% +0.04%
==========================================
Files 94 94
Lines 4574 4574
Branches 400 400
==========================================
+ Hits 4012 4014 +2
+ Misses 459 457 -2
Partials 103 103
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! Dieser Pull Request behebt einen 503-Fehler, der auftrat, wenn Browser-Benutzer ohne aktive Pangolin SSO-Session auf Backend-Daten zugreifen wollten. Durch das explizite Weiterleiten des 'X-Pangolin-Token'-Headers an das Backend wird sichergestellt, dass die Authentifizierung über den 'sso_trust_header'-Mechanismus korrekt funktioniert. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for forwarding the X-Pangolin-Token header in WithAuthFrom to allow browser users without an active SSO session to reach the UI. A corresponding unit test has been added to verify this behavior. I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…-Header) (#132) PR #130 hatte X-Pangolin-Token zur Forwarding-Liste hinzugefuegt um Browser- User ohne SSO-Session den Trust-Pfad zu ermoeglichen. Damit war der externe Pangolin-Path mit Header-Auth Bypass abgedeckt — aber Browser-User MIT aktiver Pangolin-SSO-Session bekommen weiterhin 503. Grund: Pangolin Standard-SSO setzt Remote-User als User-Identity-Header (sso_user_header). Das Backend erlaubt den SSO-Trust-Pfad nur wenn BEIDE Header gesetzt sind — X-Pangolin-Token (Trust-Signal) UND Remote-User (Identitaet). Forwarding nur eines davon → 401 → Frontend wirft 503. Fix: Remote-User zur Forwarding-Liste in WithAuthFrom hinzugefuegt. Test: TestWithAuthFromForwardsRemoteUserHeader prueft via httptest-Backend dass Remote-User beim Backend ankommt. Race-Detector grün, alle 4 Header- Forwarding-Tests passen. Refs: PR #130 (X-Pangolin-Token), Issue #131 (vom ops-agent geoeffnet als Followup zum unvollstaendigen PR #130)
…133) In Phase 7c hatten wir SSO und Bypass auf "read scope only" beschraenkt, um Leak-Defense fuer den claude-automation Bypass zu haben. Konsequenz: das HTML-Admin-UI ist via SSO nicht nutzbar, weil Admin-Routen "admin" Scope verlangen und SSO nur "read" liefert. Diese Aenderung trusted SSO und Bypass fuer den jeweils verlangten Scope. Die Defense-in-Depth ist: - SSO: Pangolin Resource Policy gated, wer ueberhaupt auf labels.* kommt. - Bypass: Secret liegt in Vault, rotiert via Vault bei Verdacht auf Leak. Production-Integrationen (Hangar, Snipe-IT, Grocy) sollen API-Keys mit spezifischem Scope nutzen, nicht den Bypass. Multi-Scope-System auf X-Label-Hub-Key API-Keys bleibt unveraendert: jeder Key hat weiterhin read/print/admin Scope-Liste und per-printer ACL. Tests: - test_pangolin_sso_blocked_on_print_scope ersetzt durch test_pangolin_sso_allows_print_and_admin_scopes (parametrisiert) - 75/75 auth + admin tests gruen, inkl. Race-Detector ADR 0014 dokumentiert die Entscheidung inkl. der zwei verworfenen Optionen (SSO-Admin-User-Liste in ENV; Scope-System komplett entfernen). Refs: Issue #78 (Phase 7c original), PR #130/#132 (Header-Forwarding), ADR 0014
…min-Routes) (#134) PR #130/#132 hatten WithAuthFrom im oapi-Client um X-Pangolin-Token und Remote-User ergänzt. forwardAuth in admin_api_keys.go ist eine zweite, parallele Implementierung für die Admin-Routes (/admin/printers, /admin/api-keys) die raw http.DefaultClient verwendet — die Header-Liste dort wurde nicht mitgezogen. Konsequenz: SSO-User konnten Read-Routes nutzen, alle Admin-Routes gaben weiterhin 503 weil das Backend mit "missing_credentials" 401 zurück lieferte. Fix: dieselbe Header-Liste in forwardAuth. Plus Regression-Test TestListPrintersPage_ForwardetPangolinSSOHeaders der httptest-Server-seitig beide Header verifiziert. Race-Detector grün, alle 4 Frontend-Packages grün. Refs PR #130 (X-Pangolin-Token), PR #132 (Remote-User), PR #133 (ADR 0014 Backend-Seite)
## 0.11.0 (2026-06-24) * feat(auth): Pangolin-SSO + Bypass für alle Scopes trusted (ADR 0014) (#133) ([4fe1a91](4fe1a91)), closes [#133](#133) [#78](#78) [130/#132](#132) * feat(nav): "Drucker" Link für Admin-Drucker-Verwaltung + getrennte ActiveNav-Werte (#135) ([1e982b0](1e982b0)), closes [#135](#135) [#104](#104) [#104](#104) [#104](#104) * fix(frontend): forward Remote-User zum Backend (Pangolin SSO-Standard-Header) (#132) ([38c0cc3](38c0cc3)), closes [#132](#132) [#130](#130) [#130](#130) [#131](#131) [#130](#130) * fix(frontend): forward X-Pangolin-Token zum Backend (Browser-User 503-Fix) (#130) ([5fb2038](5fb2038)), closes [#130](#130) * fix(frontend): forwardAuth ergänzt X-Pangolin-Token + Remote-User (Admin-Routes) (#134) ([af9ee28](af9ee28)), closes [#134](#134) [130/#132](#132) [#130](#130) [#132](#132) [#133](#133) * chore(deps): bump the go-minor-and-patch group across 1 directory with 2 updates (#128) ([a72dd90](a72dd90)), closes [#128](#128) * ci(deps): bump lewagon/wait-on-check-action in the actions-all group (#127) ([e4139ab](e4139ab)), closes [#127](#127) * docs(api): printers.yaml weg, Drucker in DB + /admin/printers Admin-UI (#124) [DRAFT] (#125) ([41bef28](41bef28)), closes [#124](#124) [#125](#125) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#3099](https://github.com/strausmann/label-printer-hub/issues/3099) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#3099](https://github.com/strausmann/label-printer-hub/issues/3099) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [#124](#124) [compose-passthrou#Pflicht](https://github.com/compose-passthrou/issues/Pflicht) [skip ci]
Bug
Browser-User ohne aktive Pangolin SSO-Session sahen 503 auf jeder UI-Route die Backend-Daten lädt —
/(Dashboard),/printers,/jobs,/templates,/admin/*. Nur/healthzfunktionierte (kein Backend-Call).Root Cause
Pangolin Resource
labels.strausmann.cloud(#123) ist mit Header-Auth konfiguriert dieX-Pangolin-Token: <trust-token>als Custom Upstream-Header an Frontend injectet. Das Backend akzeptiert diesen Token über sso_trust_header als SSO-equivalentes Signal.Aber:
WithAuthFrominfrontend/internal/api/client.go:130forwarded nur diese Headers ans Backend:X-Label-Hub-KeyX-Pangolin-UserAuthorizationX-Pangolin-TokenfehltKonsequenz: Backend bekommt keinen Auth-Header → 401 → Frontend wirft 503.
Live-Beweis (vor Fix)
Frontend GET /healthzFrontend GET /(Browser)Frontend GET /mitX-Pangolin-User: strausmannFrontend GET /mitX-Pangolin-Token: <token>Backend GET /api/printersmitX-Pangolin-UserFix
1-Zeilen-Change:
X-Pangolin-Tokenzur Forwarding-Liste inWithAuthFromhinzugefügt + Docstring präzisiert.Test
Neuer Test
TestWithAuthFromForwardsPangolinTokenHeader— RED vor Fix, GREEN danach.Volle Suite + race: alle 4 Packages grün.
Test Plan