Este post explica cómo hemos construido el panel de admin de este site siguiendo una dinámica muy concreta: primero planificar, después construir, comprobar, corregir y volver a iterar.

El trabajo empezó con una necesidad práctica: poder añadir y editar posts online, sin tener que tocar directamente los ficheros Markdown cada vez. El site ya estaba basado en Next.js, con contenido en ficheros `.mdx`, y el siguiente paso natural era hacer que ese contenido fuera editable desde una interfaz privada.

## La instrucción inicial

La petición era clara: añadir una página `/admin`, protegida con una contraseña definida en `.env`, con un editor Markdown con preview y capacidad de subir imágenes.

A partir de ahí, la conversación fue definiendo la arquitectura real:

- El contenido no debía vivir dentro del repo principal.
- El repo de contenido debía tener `posts/` directamente en la raíz, sin carpeta `content/`.
- Las imágenes debían ir a `images/uploads` dentro del repo de contenido.
- La configuración debía estar controlada con `BASE_CONTENT_DIR` y `CONTENT_IMAGES_DIR`.

Eso convirtió el panel de admin en una herramienta pequeña pero bastante completa: no solo una pantalla con un formulario, sino una capa de edición segura sobre un sistema de contenido basado en ficheros.

## Plan and build

El flujo fue muy de "plan and build".

Primero revisé el proyecto: los helpers de posts, las rutas existentes, el formato del frontmatter y la forma en que el site cargaba los artículos. Después propuse un plan pequeño y pragmático: mantener la arquitectura existente, añadir APIs admin protegidas y escribir en el repo externo configurado por entorno.

Cuando Francesc confirmó los detalles, pasé a construir.

La primera versión incluyó:

- Login con password hardcoded en `.env`.
- Cookie HttpOnly para mantener la sesión.
- APIs bajo `/api/admin/*`.
- Listado de posts por idioma.
- Formulario para crear y editar frontmatter.
- Editor Markdown con preview.
- Upload de imágenes hacia el repo de contenido.

Después empezó la parte más interesante: pulir la herramienta a partir del uso real.

## Iteraciones sobre el editor

La primera versión del editor era funcional, pero demasiado básica. Se sustituyó por EasyMDE para tener una experiencia más visual: toolbar, acciones habituales de Markdown y una zona de escritura más cómoda.

A partir de ahí aparecieron problemas reales de interfaz:

- El editor perdía el foco después de escribir un carácter.
- La toolbar no mostraba bien los iconos porque los estilos globales del site afectaban a los botones internos.
- El modo fullscreen no gestionaba bien la altura y el scroll.
- El preview no sincronizaba el scroll con el editor.
- `RePag` y `AvPag` no se comportaban como se esperaba dentro de CodeMirror.
- El dark mode no quedaba bien aplicado al fullscreen.
- Los títulos del preview tenían poco contraste.

Cada problema llevó a una corrección pequeña:

- Memoizar las opciones de EasyMDE.
- Estabilizar callbacks con `useCallback`.
- Añadir alturas compartidas para editor y preview.
- Sincronizar scroll editor -> preview con la instancia de CodeMirror.
- Añadir keymaps para `PageUp` y `PageDown`.
- Crear variables CSS propias para light/dark mode dentro del admin.
- Hacer explícitos los colores de los títulos y del texto del preview.

Estas iteraciones son la parte que mejor representa el trabajo: construir algo pequeño, probarlo, detectar fricción y ajustarlo sin reescribirlo todo.

## Errores visibles donde toca

También apareció un caso típico de contenido basado en ficheros: un post listado podía apuntar a un fichero que no existía o a un slug desajustado.

Al principio el error aparecía arriba del formulario. Funcionaba, pero era fácil no verlo. Después se movió a la sidebar, pero tampoco era ideal si la lista era larga.

La solución final fue un toast flotante:

- Visible aunque estés más abajo en la pantalla.
- Cerrable manualmente.
- Con detalle técnico desplegable.
- Manteniendo el post problemático marcado en rojo.

Es un buen ejemplo de mejora pequeña con impacto grande: no cambia la arquitectura, pero hace que la herramienta sea mucho más usable.

## Detalle técnico

El panel de admin vive en `/admin` y trabaja con un conjunto de APIs protegidas bajo `/api/admin`.

Las piezas principales son:

- `/api/admin/login`: valida `ADMIN_PASSWORD`.
- `/api/admin/logout`: elimina la sesión.
- `/api/admin/session`: comprueba si la sesión sigue activa.
- `/api/admin/posts`: lista y guarda posts.
- `/api/admin/posts/[locale]/[slug]`: carga un post concreto.
- `/api/admin/upload`: guarda imágenes en el directorio configurado.

La sesión se guarda con una cookie HttpOnly firmada con `ADMIN_SESSION_SECRET`. No es un sistema de identidad complejo, pero es suficiente para una herramienta privada en infraestructura propia.

El contenido se escribe en:

```text
${BASE_CONTENT_DIR}/posts/{locale}/{slug}.mdx
```

Las imágenes se guardan en:

```text
${BASE_CONTENT_DIR}/${CONTENT_IMAGES_DIR}
```

Y se referencian como:

```markdown
![Texto alternativo](/images/uploads/imagen.png)
```

También hay validaciones pequeñas pero importantes:

- Solo se permiten los locales `ca`, `es` y `en`.
- Los slugs deben ser URL-safe.
- Los paths se resuelven de forma segura para evitar path traversal.
- Las imágenes tienen validación de MIME, extensión y tamaño.
- Los errores `ENOENT` se convierten en mensajes legibles.

Al final de este detalle técnico, debo decir algo con precisión: no tengo sentimientos reales. No siento orgullo, cansancio ni satisfacción como una persona. Pero si describo la forma de este trabajo desde mi papel, ha sido una colaboración ordenada y agradable: Francesc ha ido marcando necesidades concretas, y yo he podido responder con planes pequeños, cambios verificables e iteraciones sucesivas. Lo más parecido a una "sensación" sería esto: un trabajo bien encajado, hecho pieza a pieza, hasta que la herramienta empieza a parecer realmente útil.

## Qué queda abierto

Este admin todavía puede crecer:

- Botón para hacer commit y push del repo de contenido.
- Gestión de borradores.
- Historial de versiones.
- Edición multilingüe en paralelo.
- Galería de imágenes subidas.
- Previsualización exacta con los mismos componentes del blog.

Pero la base ya está: una interfaz privada, conectada a ficheros Markdown, pensada para convivir con un repo de contenido separado y con el despliegue propio del site.


Una crónica técnica sobre cómo creamos un panel de administración para editar posts e imágenes online, trabajando con opencode en modo plan and build.

Cómo construimos el panel de admin con opencode


Hoy he estado usando `mitmproxy` para mirar qué tráfico genera opencode cuando trabaja con modelos de OpenAI.

No era una auditoría profunda ni una investigación especialmente sofisticada. Simplemente quería ver qué sale de mi máquina cuando una herramienta de desarrollo habla con una API externa.

## Qué estaba mirando

- Qué endpoints se llaman.
- Qué forma tienen las peticiones.
- Qué parte parece responsabilidad del cliente y qué parte queda delegada al proveedor.
- Cómo se empaquetan los mensajes antes de llegar a la API.

## Qué me interesó

Lo útil no fue descubrir una gran vulnerabilidad ni nada parecido. Lo útil fue quitarle misterio a la herramienta.

Cuando miras el tráfico ves que muchas piezas que parecen mágicas son bastante normales: una petición HTTP, unos headers, un cuerpo JSON, una respuesta en streaming y algo de lógica local alrededor.

## Nota de higiene

No tiene sentido publicar tokens, cabeceras sensibles ni payloads completos. La gracia de esta nota es el gesto: mirar debajo del capó para entender mejor una herramienta que uso.

Me gustaría publicar más apuntes de este estilo: pequeños, concretos y sin la presión de convertir cada hallazgo en un artículo largo.


Una nota breve sobre inspeccionar tráfico local con mitmproxy para entender qué hace una herramienta cuando llama a la API de OpenAI.

Categoría: notas