Das Hangfire-Dashboard in Produktion freigeben (ohne es dem Internet zu öffnen)

5. August 2026 · QueueHawk

„Dashboard Authorization obsolete" — 15.000 Forum-Aufrufe. „Dashboard nicht sichtbar auf Azure Websites" — 9.000 Aufrufe. Dieselben zwei Beschwerden sind seit Jahren die Top-Thread zum Hangfire-Produktions-Deployment, und das zugrunde liegende Problem ist älter als die Threads: das Dashboard ist standardmässig komplett offen, die offizielle Authorization-Story hat sich zweimal geändert, und jedes Team, das Hangfire deployed, stellt irgendwann dieselbe Frage — wie lasse ich die richtigen Leute auf Job-State schauen, ohne /hangfire dem öffentlichen Internet zu öffnen?

Die Default-Allow-Falle

Standardmässig akzeptiert das Hangfire-Dashboard jeden Request auf localhost, und auf den meisten Setups ist das alles — es gibt keine eingebaute Authentifizierung. In dem Moment, in dem man auf einen Server deployed, auf dem /hangfire aus dem Internet (oder aus einem internen Netzwerk, das nicht auf das eigene Team gelockt ist) erreichbar ist, hat man Job-State, Queue-Inhalte und Stack-Traces jedem exponiert, der die URL erreichen kann. Stack-Traces fehlgeschlagener Jobs enthalten oft Methodennamen, Dateipfade und partielle Argumente — nicht etwas, das man auf einem öffentlichen Endpoint haben will.

Die Authorization-Story hat sich zweimal geändert

Hangfires eigene Dashboard-Authorization hat drei Phasen durchlaufen, und die Dokumentation ist nicht immer hinterhergekommen:

• Ursprünglich: es gab keine eingebaute Authorization — man schrieb eigene OwinMiddleware oder ASP.NET-Core-Middleware, um es zu locken.
• Dann: IDashboardAuthorizationFilter wurde eingeführt, mit einer Default-Implementierung, die alle Requests auf localhost erlaubte und alle entfernten Verbindungen ablehnte. Besser, aber der „alle entfernten ablehnen"-Default bedeutete, dass das Dashboard in containerisierten, Load-Balanced- oder Reverse-Proxy-Setups unerreichbar war — jeder Request sah „entfernt" aus.
• Aktuell: IDashboardAuthorizationFilter existiert noch, aber das Default-DashboardOptions.Authorization-Array ist in vielen Setups leer, und viele Community-Anleitungen verweisen noch auf das ältere middleware-basierte Muster. Das Ergebnis ist, dass die meisten Teams entweder eine veraltete Stack-Overflow-Antwort kopieren oder das Dashboard einfach offen lassen.

Reverse-Proxy-Allow-Listing ist fragil

Ein häufiger Workaround ist, das Dashboard hinter einem Reverse Proxy zu betreiben, der nur bestimmte IPs erlaubt — eine Netzwerk-ACL auf /hangfire. Das funktioniert, bis jemandes IP sich ändert, oder ein Entwickler von einem neuen Standort aus Zugriff braucht, oder ein Stakeholder einen Blick auf „seine" Jobs haben möchte und keine Firmen-IP hat. Die ACL vergisst man auch leicht bei einem Redeploy oder einem Umzug auf ein neues Hosting. Es ist nicht, dass Reverse-Proxy-Allow-Listing falsch wäre — es löst Zugriffskontrolle auf der falschen Schicht für alles jenseits eines einzelnen internen Teams.

Die eigentliche Frage, an der Teams hängen bleiben

Hinter jedem „Dashboard Authorization"-Forum-Thread steckt dasselbe zugrunde liegende Bedürfnis: wie gebe ich bestimmten Leuten einen Blick auf bestimmte Hangfire-Instanzen, sicher, ohne alles jedem zu exponieren? Das ist ein Multi-Tenant-Authorization-Problem, kein Netzwerk-ACL-Problem. Konkret:

• Agenturen, die Hangfire über mehrere Kundenprojekte betreiben, wollen jedem Client einen Blick auf seine eigenen Jobs geben, ohne die Jobs anderer Clients zu sehen. Das eingebaute Dashboard kann das nicht — es ist per-Instanz, Single-Tenant.
• Teams mit mehreren Umgebungen (Dev/Staging/Prod) wollen einen Ort, um alle zu sehen, mit echtem Auth, nicht drei Browser-Tabs mit jeweils eigener ACL.
• Stakeholder — Kunden, Projektmanager, On-Call-Engineers — brauchen Lesezugriff auf eine Teilmenge der Jobs, keine vollen Dashboard-Admin-Rechte.

Wie ein gehostetes, auth-geschütztes Dashboard aussieht

Die saubere Trennung ist, aufzuhören, das Per-Instanz-Dashboard zu locken, und den Leuten stattdessen eine separate, authentifizierte Sicht zu geben, die aus allen Hangfire-Instanzen liest. Jede Instanz streamt State-Changes per HTTPS heraus, sobald sie passieren — kein eingehender Dashboard-Endpoint zu exponieren — und ein zentraler Service mit echter Authentifizierung (JWT, SSO, was auch immer das Team nutzt) bedient die konsolidierte Sicht.

Das ist QueueHawk: ein gehostetes Dashboard über Hangfire-Daten, mit Per-Tenant-Auth, Multi-Instanz-Aggregation und gar keinem eingehenden Dashboard-Endpoint auf dem Hangfire-Prozess. QueueHawk.Agent macht nur ausgehende HTTPS-Calls — kein Port zu öffnen, kein Reverse Proxy zu konfigurieren, keine ACL zu pflegen. Jeder User sieht nur die Applications seines Tenants; Kunden sehen nicht die Jobs anderer Kunden; On-Call-Engineers sehen alles. Der Hangfire-Prozess selbst nimmt nie wieder einen Dashboard-Request an.

Zusammenfassung

• Das Hangfire-Dashboard ist standardmässig komplett offen — /hangfire freigeben exponiert Job-State und Stack-Traces jedem, der es erreicht.
• Die Authorization-Story hat sich zweimal geändert und die Dokumentation ist inkonsistent — die meisten Teams kopieren veraltete Lösungen oder lassen es offen.
• Reverse-Proxy-Allow-Listing funktioniert für ein einzelnes Team, bricht aber bei Multi-Tenant- oder Multi-Environment-Szenarien zusammen.
• Die eigentliche Frage ist Multi-Tenant-authorisierter Zugriff auf Job-State — das ist ein gehostetes-Dashboard-Problem, kein Netzwerk-ACL-Problem.

Siehe auch: Hangfire-Job-Historie länger als 24 Stunden aufbewahren (das andere, was das eingebaute Dashboard nicht kann), Hangfire über mehrere Kundenprojekte hinweg überwachen (warum das pro Instanz schlimmer wird), und wie QueueHawk mit dem eingebauten Hangfire-Dashboard vergleicht.