From bc0bf316e1bf1906bf46d4cbaab3b2d3dda1856d Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 30 Aug 2026 12:28:10 +0200 Subject: [PATCH] gitea-mcp repariert: Container lief mit veraltetem Gitea-Token (401) Gefunden beim Versuch, F1 mit einem ECHTEN MCP-Call abzunehmen statt nur mit dem initialize-Handshake. Befund: - Container-Env GITEA_ACCESS_TOKEN = a9317c68... -> Gitea antwortet 401 - ~/.secrets/credentials.env (SSoT) = bc12ad19... -> Gitea antwortet 200 - Gitea selbst war durchgehend erreichbar (/api/v1/version -> 200) - NICHT durch den Bind-Umbau verursacht: Token-Hash vor und nach dem Recreate identisch. Der MCP war schon vorher funktionsunfaehig. Fix: Container mit dem Store-Token neu gebaut, Token per stdin (nicht argv). Abnahme jetzt ein echter tools/call user__get_my_userinfo -> login=admin id=1. Lehre (im F1-Eintrag festgehalten): ein initialize-Handshake beweist nur, dass der MCP-Prozess lebt - er liefert serverInfo auch dann, wenn jeder echte Aufruf am Backend-Token scheitert. Fuer MCPs mit Backend-Credential ist die gueltige Abnahme ein tools/call, der das Backend wirklich anfasst. Gleiches Muster wie "frische DHCP-Lease statt Registration-Table" bei WLAN. Verstaerkt F5: Container-Envs driften vom Credential-Store, weil sie ihn nie lesen. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index a5a20d5..5acb28b 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -533,6 +533,18 @@ und Letzteres verlangt die **physische Bestätigung am Gerät** — ap1 Technik per `docker run` rekonstruiert; Token über die Prozessumgebung (`-e VAR` ohne Wert), **nicht** über argv — dieselbe Klasse wie die `sshpass -p`-Falle. ⚠️ Der Nutzen ist klein: der macmini hat **nur `en0`**, `0.0.0.0` war dort faktisch schon `.167`. `n8n-mcp` blieb deshalb auf `*:3001`. + - 🔴🔴 **`gitea-mcp` war funktionsunfähig — mit einem veralteten Gitea-Token, seit unbekannter Zeit.** + Der Container trug `GITEA_ACCESS_TOKEN` = `a9317c68…`, den Gitea mit **401** ablehnt; der SSoT-Store + `~/.secrets/credentials.env` hielt längst den gültigen (`bc12ad19…`, **200**). Gitea selbst war die + ganze Zeit erreichbar (`/api/v1/version` → 200). Fix: Container mit dem Store-Token neu gebaut + (Token per **stdin**, nicht argv). Abnahme = echter API-Call `user__get_my_userinfo` → `login=admin`. + ⚠️ **Nicht durch den Recreate verursacht:** der Token-Hash war vor und nach dem Bind-Umbau identisch. + 🔑 **Die eigentliche Lehre ist die Abnahme-Methode:** ein `initialize`-Handshake beweist nur, dass + der MCP-**Prozess** lebt — er antwortet mit `serverInfo` auch dann, wenn jeder echte Aufruf am + Token scheitert. Die erste Verifikation dieser Session sah deshalb grün aus und war es nicht. + **Für MCPs mit Backend-Credential ist die gültige Abnahme ein `tools/call`, der das Backend + wirklich anfasst** — dasselbe Muster wie „frische DHCP-Lease statt Registration-Table" bei WLAN. + Direkt daraus folgt **F5**: die Container-Envs driften vom Store, weil sie ihn nie lesen. - ⚪ **Tote Diagnose-Permissions entfernt:** `blaueblueten-n8n/.claude/settings.local.json` hatte 3× `Bash(dig/host/curl … gitea-mcp.emsenhuber.net)` in der `allow`-Liste (10→7 Einträge). Das waren **keine** MCP-Verbindungen — `enabledMcpjsonServers: ["gitea-mcp"]` gibt per **Name** frei und