Save plan in Lovable

.lovable/plan.md

@@ -1,60 +1,55 @@
 
-Objectif
-- Fiabiliser l’authentification des Edge Functions sur ta VM Supabase self-hosted et corriger le test `update-feed`.
-
-Constat confirmé dans le code
-- `update-feed` accepte bien 3 accès: `x-cron-secret`, `service_role`, ou super-user.
-- Le vrai point faible est dans `supabase/functions/_shared/security.ts`: `validateCronSecret()` ne lit que `Deno.env.get('CRON_SECRET')`.
-- En parallèle, les jobs SQL du projet lisent le secret depuis `public.app_secrets` avec la clé `cron_secret`.
-- Donc sur ta VM, si `CRON_SECRET` n’est pas injecté dans le runtime Edge Functions, ton header `x-cron-secret` sera refusé même si la valeur est correcte côté base.
-- Ta commande de test a aussi une payload incorrecte: `update-feed` attend `feedId` et `url`, pas `name`.
-
-Plan d’implémentation
-1. Unifier la source du cron secret
-   - Faire évoluer `validateCronSecret` pour vérifier d’abord `CRON_SECRET` dans l’environnement.
-   - Si absent, fallback sécurisé vers `public.app_secrets` via un client `service_role`.
-   - Conserver un comportement “fail closed” si aucun secret n’est disponible.
-
-2. Mettre à jour les fonctions impactées
-   - Adapter les appels à `validateCronSecret` dans :
-     - `supabase/functions/update-feed/index.ts`
-     - `supabase/functions/fetch-rss/index.ts`
-     - `supabase/functions/purge-articles/index.ts`
-   - Passer le helper en asynchrone et harmoniser les messages de logs.
-
-3. Améliorer le diagnostic self-hosted
-   - Ajouter des logs distincts pour :
-     - secret absent dans l’environnement
-     - secret absent en base
-     - secret présent mais invalide
-   - Cela permettra d’identifier immédiatement si le problème vient de la VM ou de la requête.
-
-4. Ajouter une couverture de test
-   - Cas 1: `CRON_SECRET` présent dans l’environnement
-   - Cas 2: fallback `app_secrets`
-   - Cas 3: token `anon` + bon `x-cron-secret` = autorisé
-   - Cas 4: secret manquant/invalide = 401
-
-5. Corriger la documentation de test
-   - Documenter la vraie payload de `update-feed` :
+
+## Diagnostic
+
+Le site reste bloqué sur "Chargement des articles..." car les requêtes vers `https://data.duhaz.fr` (REST API, Auth) reçoivent l'erreur "No API key found in request" de Kong.
+
+Le client Supabase JS envoie automatiquement un header `apikey: <clé>` dans chaque requête. Kong attend ce header. Si Caddy ne le transmet pas correctement, Kong rejette la requête.
+
+## Cause probable
+
+Caddy transmet normalement tous les headers par défaut. Les causes possibles :
+1. **Le Caddyfile n'est pas un simple `reverse_proxy`** — il y a peut-être un `header_up` qui filtre ou un `handle` mal configuré
+2. **Caddy fait du TLS termination** mais Kong attend aussi du HTTPS en interne, causant un conflit
+3. **Le path ne couvre pas toute l'API** — seuls `/functions/` est proxié, pas `/rest/`, `/auth/`, etc.
+
+## Plan
+
+### Etape 1 — Vérifier et corriger le Caddyfile
+
+Ta configuration Caddy devrait ressembler à ceci pour proxier **tout** le trafic vers Kong :
+
+```text
+data.duhaz.fr {
+    reverse_proxy localhost:8000
+}
+```
+
+C'est tout. Pas de filtrage de headers, pas de restriction de path. Caddy gère le TLS côté externe et parle en HTTP vers Kong sur le port 8000.
+
+Si tu as quelque chose de plus complexe (des `handle /functions/*` séparés, des `header_up -apikey`, etc.), c'est probablement la source du problème.
+
+### Etape 2 — Tester la connectivité manuellement
+
+Depuis ta VM, teste que Kong reçoit bien le header `apikey` :
+
 ```bash
-curl -L -X POST 'http://192.168.1.244:8000/functions/v1/update-feed' \
-  -H 'Authorization: Bearer <ANON_OU_SERVICE_ROLE>' \
-  -H 'x-cron-secret: <CRON_SECRET>' \
-  -H 'Content-Type: application/json' \
-  --data '{"feedId":"<FEED_ID>","url":"<FEED_URL>"}'
+curl -v https://data.duhaz.fr/rest/v1/ \
+  -H "apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6IndmdHl1a3VnZWR0b2ppemdhdHdqIiwicm9sZSI6ImFub24iLCJpYXQiOjE3NDkzNjIxNTEsImV4cCI6MjA2NDkzODE1MX0.KflrS6WiGksws1nO8NDm5i_Dav4u2JDSuEYtEnmKCRE"
 ```
-   - Préciser que sans fallback, il faut absolument définir `CRON_SECRET` dans le runtime Edge de la VM.
-
-Détails techniques
-- Fichiers principaux à modifier :
-  - `supabase/functions/_shared/security.ts`
-  - `supabase/functions/update-feed/index.ts`
-  - `supabase/functions/fetch-rss/index.ts`
-  - `supabase/functions/purge-articles/index.ts`
-- Cause racine la plus probable :
-  - le runtime Edge self-hosted n’a pas `CRON_SECRET`
-  - alors que la base utilise déjà `public.app_secrets`
-- Résultat attendu :
-  - tes appels curl avec `x-cron-secret` fonctionneront sur la VM même si le secret n’est stocké qu’en base
-  - le prochain éventuel blocage sera la validation des champs `feedId` et `url`, pas l’authentification
+
+Si ça échoue via `data.duhaz.fr` mais fonctionne en direct sur `localhost:8000`, le problème est confirmé côté Caddy.
+
+### Etape 3 — Alternative si le proxy reste problématique
+
+Si corriger le proxy prend du temps, on peut adopter une approche hybride dans le code :
+- Garder `SUPABASE_URL` pointant vers le cloud (`https://wftyukugedtojizgatwj.supabase.co`) pour les requêtes REST/Auth
+- Utiliser `https://data.duhaz.fr` uniquement pour les appels Edge Functions (via `fetch` direct)
+
+Cela éviterait le problème de proxy pour l'API REST tout en utilisant ta VM pour les fonctions.
+
+### Ce qu'il faut faire maintenant
+
+1. **Partage ton Caddyfile** (ou la partie concernant `data.duhaz.fr`) pour que je puisse identifier le problème exact
+2. Ou **teste la commande curl** ci-dessus pour confirmer si le header `apikey` passe correctement
+