diff --git a/docs/session-20260828-decisions.md b/docs/session-20260828-decisions.md index 283e1f4..22b4f4a 100644 --- a/docs/session-20260828-decisions.md +++ b/docs/session-20260828-decisions.md @@ -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. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 9eb7729..8f2a7e4 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -487,6 +487,23 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine explizite `forward`-Zeile — s. TP5 Etappe 2. +#### 🆕 Notiz 2026-08-28 — n8n-mcp Accept-Header-Strike + Auth-Sanierung +- **Live-Befund (opencode-Probing)**: `n8n-mcp` antwortet auf POST mit nur `Accept: application/json` mit + `HTTP 406 Not Acceptable: Client must accept both application/json and text/event-stream`. Mit korrektem + Accept-Header (= StreamableHTTP-Modus) antwortet derselbe Server `HTTP 200` mit + `serverInfo: n8n-documentation-mcp 2.57.1`. ⇒ opencode's `mcp list` zeigt `failed` zu Unrecht — Sidebar + bleibt Wahrheit. Volle Diagnose im Session-Anker + [`docs/session-20260828-decisions.md`](session-20260828-decisions.md), Abschnitt + „MCP-Status-Check (Cold-Start-Race + Accept-Header-Strike)". +- **Konsequenz für TP16.3**: ein künftiges Caddy-Fronting für n8n-mcp **muss** den SSE-Header durchreichen + (`proxy_pass` mit angepasstem `Accept`-Default `application/json, text/event-stream`, oder + Caddy mit `header_up`). Sonst antwortet das Backend weiter 406, und die Symptomatik bleibt + unsichtbar — der Tunnel steht, aber der Probe schlägt fehl. +- **Auth-Sanierung**: Anwender-Direktive 2026-08-28 „alle Tools laufen über Caddy oder CF + Caddy + (extern), Bearer-Authentifizierung einmal sauber". Gehört thematisch in TP16.3, **nicht** als neuer + TP — siehe Quick-Index Zeile TP16.3. Bezug zu **TP35** Schicht 2: Reihenfolge ist TP16.3 → TP35. + TP35 wartet mit Schicht 2, bis das Fronting steht. + ### TP17.1 — Shelly Gen4 raus aus dem WLAN ▸ ❌ **VERWORFEN (2026-08-23) — Weg bewiesen, Ziel damit nicht erreichbar** — 📋 `docs/tp17.1-shelly-gen4-funkmigration-runbook.md` > ❌ **User-Entscheid 2026-08-23 nach dem Pilot: stoppen und zurückbauen.** Auslöser war Christophs > strukturelle Frage: *„zigbee sollte die antwort auf die vielen radios auf -iot geben. nutzt aber