admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

drift-korrektur: Auth-Sanierung (Bearer) gehört in TP16.3, nicht als Vorab-Notiz

Browse Source 
TP16.3 existiert seit 2026-08-17 (Quick-Index Z. 194, Body Z. 401,
Runbook tp16.3-nautobot-mesh-only-runbook.md) und deckt 'alle Tools
über Caddy oder CF + Caddy (extern)' + Auth-Sanierung bereits ab.

Mein Fehler: ich habe im Index nicht nachgeschaut und einen Vorab-Punkt
formuliert, der TP16.3 doppelt. Anwender hat das in dieser Session
explizit markiert ('das darf dir kein 2. mal passieren').

Fix:
- Session-Anker: Vorab-Notiz entfernt, ersetzt durch Verweis auf TP16.3.
- TP16.3-Body: technische Notiz 'n8n-mcp Accept-Header-Strike +
  Auth-Sanierung' eingepflegt (SSE-Header-Konsequenz für künftiges
  Caddy-Fronting, Reihenfolge TP16.3 → TP35 Schicht 2).

Lehre: vor jeder Aussage 'gibt's noch nicht' oder 'neuer TP nötig':
erst grep auf den Quick-Index in teilprojekte.md.
This commit is contained in:
claude-code
2026-08-28 17:18:16 +02:00
parent a2465b8586
commit 5797364e4d
2 changed files with 24 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/session-20260828-decisions.md
View File

@@ -95,14 +95,13 @@ Beim ersten Aufruf von `opencode mcp list` kann einzelne Server als `✗ failed`
Diskussion hat ~1 Stunde gedauert, Ergebnis sind 3 Commits (Handoff + TP35 + dieser Anker), 12 valide Backups, 1 synology-Sync als zusätzliche Sicherung. Ausführung der TP35-Schichten erfolgt in separaten Sessions, pro Projekt einer.
## Auth-Sanierung (Bearer) — Vorab-Notiz für „Cloudflare Tunnels"-Punkt
## Auth-Sanierung (Bearer) — gehört in TP16.3
**Anwender-Direktive 2026-08-28**: es kommt ein eigener Punkt zu Cloudflare Tunnels. Ziel: **alle Tools laufen über Caddy oder CF + Caddy (extern)**. Im selben Zug soll die **Bearer-Authentifizierung einmal sauber gelöst** werden — vermutlich in Form eines zentralen Auth-Proxys / Identity-Provider auf Caddy-Ebene, statt Bearer-Tokens verteilt in `~/.secrets/exports.zsh`.
🔴 **Drift-Korrektur (Anwender 2026-08-28)**: dieser Punkt **existiert bereits** — **TP16.3** „cloudflared-Reduktion: was der Mesh als Datenpfad kann (und was nicht)", ⏳ Probe läuft seit 2026-08-24, Sektion `docs/teilprojekte.md` Zeile 401, Quick-Index Zeile 194, Runbook `docs/tp16.3-nautobot-mesh-only-runbook.md`. Mein Fehler: ich habe im Index nicht nachgeschaut und einen „Vorab-Punkt" formuliert, der TP16.3 doppelt. **Technische Notiz in TP16.3 selbst eingepflegt** (`🆕 Notiz 2026-08-28 — n8n-mcp Accept-Header-Strike + Auth-Sanierung` direkt nach dem TP16.3-Body), mit dem Befund, der SSE-Header-Konsequenz für künftiges Caddy-Fronting, und der Reihenfolge-Regel TP16.3 → TP35.
**Was das für n8n-mcp konkret heißt**: das Accept-Header-Strike-Problem (siehe oben) wird **mit** dem Tunnel-Punkt gelöst, **nicht** heute. Bis dahin: Sidebar-Status ist Wahrheit, `mcp list` zeigt `failed` zu unrecht.
**Was in TP16.3 inhaltlich gehört** (nicht in den Anker):
- n8n-mcp Accept-Header-Strike (406): gehört als **technische Notiz** in TP16.3, weil dort das „Caddy oder CF + Caddy"-Fronting sowieso diskutiert wird.
- Bearer-Authentifizierung einmal sauber: gehört in TP16.3, weil der TP-Scope „cloudflared-Reduktion + Caddy-Fronting" genau diesen Auth-Pfad vorsieht.
- TP35 Schicht 2 (Credentials-Schichtung) Endform: **bleibt** TP35, aber **Endform** hängt von TP16.3 ab — Reihenfolge ist also: erst TP16.3 klärt das Fronting, dann TP35 Schicht 2 zieht nach.
**Was das für TP35 bedeutet**: TP35 Schicht 2 (Credentials-Schichtung) wird durch den Tunnel-Punkt **nicht obsolet**, aber die Endform ist anders — statt `{env:...}` pro MCP-Config kommt ein Caddy-Forward mit zentraler Auth. Schicht 2 wird also **erst** sinnvoll, wenn der Tunnel-Punkt steht.
**TP-Vorschlag (für später, nicht jetzt anlegen)**: ein TP „Cloudflare-Tunnel + Caddy als Tool-Auth-Gateway", Scope: alle MCP-Backends hinter CF-Tunnel, Auth per CF Access oder Caddy-Forward, Bearer-Tokens nur noch intern zwischen Caddy und Backend.
**Nicht-Inhalt** für diese Session: keine Bearer-Migration, keine Caddy-Änderung, kein neuer TP. Nur dokumentiert.
**Merkregel für mich**: vor jeder Aussage „gibt's noch nicht" oder „neuer Punkt nötig": **erst `grep` auf den Quick-Index in `teilprojekte.md`**. Doppel-Claims sind Drift, auch in der Doku. Anwender hat das in dieser Session explizit hervorgehoben („das darf dir kein 2. mal passieren") — als Lernschritt übernommen.