Ahora con creación de páginas por IA vía el servidor MCP

Vista previa de borradores

La API de entrega devuelve solo contenido publicado. Tres mecanismos dejan que las personas adecuadas vean borradores sin abrir esa puerta a todos.

Las lecturas públicas devuelven contenido publicado y nada más. Es una propiedad de la API, no un filtro que tu app deba recordar aplicar, y por eso una página sin terminar no puede filtrarse por accidente.

También significa que ver un borrador exige demostrar deliberadamente quién eres. Hay tres vías, para tres personas distintas.

Quien revisa un cambio quiere el borrador en la URL real, sin un editor de por medio. La ruta /api/draft fija una cookie que conmuta la ruta pública a contenido borrador:

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

La ruta valida el secreto contra CMSSY_DRAFT_SECRET, fija la cookie y redirige al slug. A partir de ahí ese navegador ve borradores hasta que la cookie se borre. Todos los demás siguen viendo el sitio publicado.

2. Capa de borrador de dev: para ti, mientras desarrollas

Añade ?cmssyDev=1 a cualquier URL para renderizar tu capa de borrador personal:

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

No es el borrador compartido, sino tu copia de trabajo personal, y eso es lo que la hace segura para probar un bloque aún sin desplegar: a nadie más le cambia la vista previa.

Requiere CMSSY_API_TOKEN y está pensada para desarrollo. Sin el flag obtienes contenido publicado, así que dejar el token puesto no cambia lo que ven los visitantes.

3. Modo edición: para el editor

El iframe del editor envía cmssyEdit=1 más un cmssySecret que coincida. El middleware verifica el par y reescribe a /cmssy-edit, que sirve contenido borrador y monta el puente de edición.

Un ?cmssyEdit=1 sin verificar no hace nada. Lo comprueba la prueba de humo, porque una ruta de vista previa que se fía de una cadena de consulta es una fuga pública de borradores con pasos extra: consulta pruebas.

Los secretos

  • CMSSY_DRAFT_SECRET: protege el puente de vista previa y el modo edición. Cualquier cadena aleatoria; solo debe coincidir con lo que envía el panel.
  • CMSSY_API_TOKEN: necesario para la capa ?cmssyDev=1, porque leer el borrador personal de alguien es una operación autenticada.
  • CMSSY_REVALIDATE_SECRET: protege el webhook /api/revalidate, que es otro asunto: invalida caché tras publicar y no expone borradores.

Define CMSSY_ADMIN_URL si alojas el panel por tu cuenta; el banner de borrador lo usa para su enlace "Abrir en el editor".

Publicar y la caché

Publicar no despliega, y tampoco aparece automáticamente. Tu ruta pública cachea según su propio revalidate, así que una página recién publicada puede seguir sirviendo la copia antigua hasta que pase esa ventana.

El webhook /api/revalidate cierra ese hueco: cmssy lo llama al publicar y la ruta invalida las rutas afectadas. Si un cambio está publicado y el sitio sigue mostrando la versión vieja, revisa ese webhook antes de sospechar del CMS.

Siguientes pasos

  • Rutas y páginas: las tres formas de petición a las que sirven estos mecanismos.
  • Pruebas: demostrar que el modo edición sigue rechazando peticiones sin verificar.
  • Tokens de API: crear y acotar CMSSY_API_TOKEN.