nas-runbooks/common/baserow-mcp-oauth-fix.md

baserow-mcp-oauth-fix — sidecar OAuth devant Baserow (28/07/2026)

Statut : PRODUCTION. Reverse-proxy DSM bascule 3888->3887 le 28/07/2026, valide en public (well-known/register/app web/API tous 200/302 comme attendu). Connecteur claude.ai a reconnecter cote Nabil si pas deja fait.

Probleme

Connecteur Claude.ai vers Baserow MCP (https://baserow.bolbol.tn/mcp/<token>/sse) : « Impossible de s'inscrire aupres du service de connexion de Baserow ».

Cause : meme piege que mcp-vps.md/mcp-nas — Claude.ai sonde systematiquement /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource et POST /register a l'ajout d'un connecteur MCP personnalise, meme quand le serveur cible n'a besoin d'aucune auth (la vraie protection Baserow = le token secret deja dans l'URL /mcp/<token>/sse). Baserow (Caddy + Nuxt) renvoie 404 (page Nuxt generique, pas une 404 backend) sur ces 3 routes → echec du handshake connecteur.

Difference avec mcp-vps/mcp-nas : ceux-la sont du code Python maison, patchable directement. Baserow est l'image officielle (watchtower la met a jour) — impossible de patcher son code source sans que ca saute au prochain rebuild/update.

Fix

Sidecar devant Baserow, sans toucher a l'image Baserow : /volume1/docker/baserow-oauth-stub (2 containers, reseau n8n uniquement) :

• baserow-oauth-app (Starlette/uvicorn, build local, pas de port publie) : /register, /authorize, /token — meme pattern PKCE que linux_mcp_server.py (mcp-vps), CLIENT_ID = claude-baserow-mcp, tokens jamais verifies ailleurs (la seule vraie protection reste le token dans l'URL Baserow).
• baserow-oauth-proxy (nginx:alpine, port 3887→80, reseau n8n) :
  • /.well-known/oauth-authorization-server et /.well-known/oauth-protected-resource(/*) → JSON statique (fichiers montes en volume, pas de logique dynamique necessaire)
  • /register, /authorize, /token → proxy vers baserow-oauth-app:8080
  • location / (tout le reste : app web, API, /ws/*, /mcp/*/sse) → proxy transparent vers baserow:80 (alias Docker du container Baserow sur le reseau n8n), avec support WebSocket (map $http_upgrade $connection_upgrade) et SSE (proxy_buffering off, proxy_read_timeout 3600s, chunked_transfer_encoding on).

Gotcha reseau (couteux a redecouvrir)

Premiere tentative : 2 services sur un reseau default cree par le compose (nouveau bridge custom) + le service nginx en plus sur n8n. Resultat : ping fonctionne entre les 2 containers, mais toute connexion TCP (nc, wget, proxy_pass) time out en silence (502/504 selon le point de test) — alors que Baserow lui-meme (deja sur n8n) passait sans probleme. Hypothese : regle firewall (crowdsec-firewall-bouncer ou iptables DOCKER-USER) qui n'autorise le trafic TCP inter-conteneurs que sur les reseaux Docker deja connus/etablis (n8n), pas sur un reseau tout juste cree. Fix : mettre les 2 services UNIQUEMENT sur le reseau externe n8n (pas de reseau default supplementaire) — resout immediatement le probleme, ping ET TCP passent. A retenir pour tout futur sidecar : privilegier un reseau externe deja peuple plutot qu'un nouveau bridge, si un blocage TCP-mais-pas-ICMP apparait entre 2 conteneurs.

Tests de validation (28/07/2026)

Tous compares en baseline (direct port 3888, bypass total du sidecar) vs via le proxy (port 3887) :

Test	Baseline 3888	Via proxy 3887
/.well-known/oauth-authorization-server	404 (Baserow)	200 JSON statique
/.well-known/oauth-protected-resource	404 (Baserow)	200 JSON statique
POST /register	404 (Baserow)	201, client_id: claude-baserow-mcp
GET /authorize + PKCE S256 → POST /token	n/a	200, access_token + refresh_token
GET /mcp/<token>/sse (bon Host header)	200, event endpoint	200, event endpoint identique
GET / (app web)	302 (redirect login)	302 identique
GET /api/_health/	200	200 identique
Upgrade WebSocket /ws/core/	101 Switching Protocols	101 identique

Piege methodologique note en passant : tester /mcp/<token>/sse en curl direct sur le port 3888 SANS forcer Host: baserow.bolbol.tn renvoie un faux-negatif (404 JSON generique Nuxt) — le Caddyfile de Baserow route /api/* /ws/* /mcp/* /assistant/* vers le backend uniquement si l'expression @is_baserow_tool matche BASEROW_PUBLIC_URL sur le Host recu ; sinon fallback silencieux vers le frontend Nuxt qui 404 proprement. Toujours forcer le bon Host en test local.

Action manuelle (faite le 28/07/2026)

Reverse-proxy DSM baserow.bolbol.tn bascule 3888 → 3887. Verifie en public immediatement apres : well-known x2, register, app web (302), API (200) tous identiques au comportement attendu. Reversible en 10 secondes (remettre 3888) si jamais un probleme apparait plus tard.

Fichiers

/volume1/docker/baserow-oauth-stub/ : oauth_app.py, Dockerfile, nginx.conf, oauth-authorization-server.json, oauth-protected-resource.json, docker-compose.yml (miroir complet pousse dans ce commit, sous common/baserow-oauth-stub/).