Dashboard-Auth: Hermes-eigene Auth nicht mehr Pflicht, Caddy reicht

Dashboard bindet seit dem Caddy-Umbau nur noch auf 127.0.0.1 -- Hermes'
Auth-Gate engagiert sich laut eigener Fehlermeldung NUR bei einem
0.0.0.0-Bind, greift also gar nicht mehr. HERMES_DASHBOARD_PASSWORD_HASH
ist damit optional statt Pflicht (kein docker-compose-Abbruch mehr bei
leerem Wert), der dashboard: basic_auth-Block in config.yaml.example ist
standardmaessig auskommentiert. Caddy (TLS + eigene Basic-Auth) bleibt
die einzige im Normalbetrieb noetige Auth-Schicht. README/.env.example
entsprechend entschlackt -- Hash-Erzeugen + Dollarzeichen-Escaping nur
noch als Fallback dokumentiert, falls der Bind mal wieder auf 0.0.0.0
wandert.

hermes-agent-config/config.yaml.example

@@ -32,26 +32,27 @@ model:
   # (den Hermes intern nutzt) setzt den Header automatisch aus diesem Feld.
   api_key: "${HERMES_GATEWAY_TOKEN}"
 
-# ─── Dashboard-Auth ─────────────────────────────────────────────────────
-# Seit 19.07.2026 Pflicht: Hermes verweigert den Bind des Dashboards auf
-# 0.0.0.0 komplett, wenn kein Auth-Provider registriert ist ("Refusing to
-# bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback binds,
-# but no auth providers are registered"). Ohne diesen Block bindet's nur
-# noch auf 127.0.0.1 (Tunnel), egal was im docker-compose `command:` steht.
+# ─── Dashboard-Auth (standardmaessig AUSKOMMENTIERT) ────────────────────
+# Hermes' eigenes Auth-Gate verweigert den Bind des Dashboards auf 0.0.0.0
+# komplett, wenn kein Auth-Provider registriert ist ("Refusing to bind
+# dashboard to 0.0.0.0 — the auth gate engages on non-loopback binds, but
+# no auth providers are registered") — greift aber laut derselben Meldung
+# NUR bei einem 0.0.0.0-Bind. Unser docker-compose.yml bindet das Dashboard
+# bewusst auf 127.0.0.1 und stellt es per Caddy-Reverse-Proxy (TLS + eigene
+# Basic-Auth) nach aussen bereit — das Gate hier engagiert sich dabei gar
+# nicht erst, dieser Block ist im Normalbetrieb also NICHT noetig.
 #
-# Hash EINMALIG erzeugen (NICHT das Klartext-Passwort committen oder in .env
-# schreiben — nur den Hash). Gegen den "hermes-agent"-Container, NICHT
-# "hermes-agent-dashboard" — der braucht HERMES_DASHBOARD_PASSWORD_HASH schon
-# zum Hochfahren (Henne-Ei-Problem: ohne Hash kein Start, ohne laufenden
-# Container kein Hash). "hermes-agent" teilt sich dasselbe Image und laeuft
-# auch ohne den Wert:
+# Nur falls Du den Dashboard-Bind mal direkt auf 0.0.0.0 stellst (z.B. ohne
+# Caddy testen): Block unten einkommentieren + HERMES_DASHBOARD_PASSWORD_HASH
+# in .env setzen. Hash EINMALIG erzeugen (NICHT das Klartext-Passwort
+# committen oder in .env schreiben — nur den Hash), gegen den "hermes-agent"-
+# Container, NICHT "hermes-agent-dashboard" (der braucht den Hash schon zum
+# Hochfahren, Henne-Ei-Problem):
 #   docker exec -it hermes-agent python -c \
 #     "from plugins.dashboard_auth.basic import hash_password; print(hash_password('DEIN-PASSWORT'))"
 # Ergebnis nach .env als HERMES_DASHBOARD_PASSWORD_HASH eintragen.
 #
-# ${HERMES_DASHBOARD_USER} / ${HERMES_DASHBOARD_PASSWORD_HASH} werden wie
-# oben von Hermes selbst aus den Container-Env-Vars expandiert.
-dashboard:
-  basic_auth:
-    username: "${HERMES_DASHBOARD_USER}"
-    password_hash: "${HERMES_DASHBOARD_PASSWORD_HASH}"
+# dashboard:
+#   basic_auth:
+#     username: "${HERMES_DASHBOARD_USER}"
+#     password_hash: "${HERMES_DASHBOARD_PASSWORD_HASH}"