Désormais avec création de pages par IA via le serveur MCP

Aperçu brouillon

L'API de diffusion ne renvoie que du contenu publié. Trois mécanismes permettent aux bonnes personnes de voir les brouillons sans ouvrir la porte à tout le monde.

Les lectures publiques renvoient du contenu publié, et rien d'autre. C'est une propriété de l'API, pas un filtre que votre application doit penser à appliquer - d'où l'impossibilité qu'une page inachevée fuite par accident.

Cela signifie aussi que voir un brouillon exige de prouver délibérément qui vous êtes. Il y a trois voies, pour trois personnes différentes.

1. Cookie de brouillon - pour les relecteurs

Un collègue qui relit un changement veut le brouillon sur la vraie URL, sans éditeur devant. La route /api/draft pose un cookie qui bascule la route publique sur le contenu brouillon :

/api/draft?secret=...&slug=/pricing

La route valide le secret contre CMSSY_DRAFT_SECRET, pose le cookie et redirige vers le slug. Dès lors, ce navigateur voit les brouillons jusqu'à effacement du cookie. Tous les autres continuent de voir le site publié.

2. Calque brouillon de dev - pour vous, pendant le développement

Ajoutez ?cmssyDev=1 à n'importe quelle URL pour afficher votre calque de brouillon personnel :

http://localhost:3000/pricing?cmssyDev=1

Ce n'est pas le brouillon partagé, mais votre copie de travail personnelle - ce qui la rend sûre pour essayer un bloc pas encore déployé : l'aperçu de personne d'autre ne change.

Cela requiert CMSSY_API_TOKEN et vise le développement. Sans le paramètre, vous obtenez le contenu publié : laisser le jeton défini ne change donc rien à ce que voient les visiteurs.

3. Mode édition - pour l'éditeur

L'iframe de l'éditeur envoie cmssyEdit=1 plus un cmssySecret correspondant. Le middleware vérifie la paire et réécrit vers /cmssy-edit, qui sert le contenu brouillon et monte le pont d'édition.

Un ?cmssyEdit=1 non vérifié ne fait rien. Le test de fumée le vérifie, car une route d'aperçu qui fait confiance à une chaîne de requête est une fuite publique de brouillons avec des étapes en plus - voir tests.

Les secrets

  • CMSSY_DRAFT_SECRET - protège le pont d'aperçu brouillon et le mode édition. Une chaîne aléatoire quelconque ; elle doit seulement correspondre à ce qu'envoie l'admin.
  • CMSSY_API_TOKEN - requis pour le calque ?cmssyDev=1, car lire le brouillon personnel de quelqu'un est une opération authentifiée.
  • CMSSY_REVALIDATE_SECRET - protège le webhook /api/revalidate, autre sujet : il invalide le cache après publication et n'expose aucun brouillon.

Définissez CMSSY_ADMIN_URL si vous hébergez l'admin vous-même ; la bannière de brouillon s'en sert pour son lien « Ouvrir dans l'éditeur ».

Publication et cache

Publier n'est pas déployer - et cela n'apparaît pas automatiquement non plus. Votre route publique met en cache selon son propre revalidate : une page fraîchement publiée peut donc continuer à servir l'ancienne copie jusqu'à la fin de cette fenêtre.

Le webhook /api/revalidate comble l'écart : cmssy l'appelle à la publication et la route invalide les chemins concernés. Si un changement est publié mais que le site montre encore l'ancienne version, vérifiez ce webhook avant de soupçonner le CMS.

Étapes suivantes

  • Routes et pages - les trois formes de requête que servent ces mécanismes.
  • Tests - prouver que le mode édition rejette toujours les requêtes non vérifiées.
  • Jetons API - créer et limiter CMSSY_API_TOKEN.