Pekke: la lista de nacimiento multi-tienda y sin comisiones

Una lista de nacimiento se comparte por WhatsApp y se abre desde el móvil de gente que nunca ha oído hablar de Pekke. Eso obliga a que el HTML llegue montado desde el servidor: si los regalos los pintara el navegador después de descargar y ejecutar JavaScript, ni el buscador vería el contenido al indexar, ni WhatsApp podría componer la tarjeta con título e imagen al pegar el enlace, porque el robot que la genera no ejecuta JavaScript. La tarjeta no es un detalle estético: es lo primero que ve la familia a la que le llega el enlace.

El panel de los padres es el caso contrario. Está detrás de un login, no hay nada que indexar y todo su valor está en la interacción. Se monta como isla client:only: el servidor no lo renderiza siquiera. Renderizarlo también en servidor solo añadiría latencia y el descuadre clásico entre lo que pinta el servidor y lo que pinta el cliente en una vista que depende de la sesión.

Astro permite tomar esa decisión página a página en lugar de para toda la aplicación, y ese es exactamente el motivo de haberlo elegido: la parte pública va renderizada en servidor y la privada va en el navegador, dentro del mismo proyecto y con el mismo código de dominio. Las piezas interactivas de la lista —los filtros, el diálogo de reserva— son islas de Vue que se hidratan sobre un HTML que ya es correcto sin ellas.

El invitado entra por un enlace, no tiene cuenta y no va a crearla. La operación «este regalo lo llevo yo» tiene que poder ejecutarla alguien anónimo, y ahí aparece el problema: si para eso le das permiso de escritura sobre la tabla de regalos, le has dado permiso para todo lo demás que se puede hacer con esa tabla —liberar la reserva de otro, cambiar un precio, tocar la lista de una familia distinta—.

Por eso la reserva no es un UPDATE lanzado desde el cliente. Todas las tablas tienen RLS (seguridad a nivel de fila) activa, que por defecto no deja escribir nada. Encima hay una única función SECURITY DEFINER: se ejecuta con los privilegios de su propietario, comprueba que el regalo existe y sigue disponible, y hace exactamente esa transición y ninguna otra. Lo que queda expuesto al público no es una tabla, es una operación con sus reglas dentro. Ampliar lo que puede hacer un invitado obliga a escribir otra función, no a aflojar un permiso.

Después, la reserva se confirma por correo. El invitado deja su email, recibe un enlace con un token y hasta que no lo abre la reserva no es definitiva: eso prueba que la dirección es suya y evita que alguien bloquee media lista con correos inventados. Si no confirma en 48 horas, la reserva caduca y el regalo vuelve a estar disponible. Sin esa caducidad, cada reserva abandonada dejaría un regalo bloqueado para siempre, que es la forma más silenciosa que tiene una lista de nacimiento de quedarse inservible.

Lo que hace multi-tienda a Pekke es que el usuario pega la URL de un producto y el servidor va a buscarla y extrae nombre, precio e imagen. Un servidor que descarga URLs dictadas por un desconocido es la definición de un SSRF: si no se controla, cualquiera puede pedirle que se conecte a direcciones internas —127.0.0.1, el rango privado de la red, el endpoint de metadatos del proveedor de nube— y usarlo como proxy hacia dentro de la infraestructura.

La comprobación intuitiva es mirar el nombre de dominio y rechazar los sospechosos. No sirve, porque quien controla el dominio controla también su DNS: el nombre pasa el filtro y, cuando el cliente HTTP lo resuelve otra vez para conectarse, esa segunda resolución devuelve 127.0.0.1. Entre la comprobación y la conexión ha cambiado la respuesta. Eso es DNS rebinding, y contra él una validación estática del hostname no hace nada.

Pekke resuelve el DNS primero, valida las direcciones IP obtenidas contra los rangos de loopback, privados y de enlace local, y lanza la petición contra la dirección ya validada. Se comprueba y se conecta sobre la misma resolución, así que no queda hueco entre una cosa y la otra.

Importar productos y reservar regalos son operaciones abiertas, así que el límite hay que ponerlo por IP. Y la IP hay que sacarla de la cabecera x-forwarded-for, que es una lista y tiene una trampa conocida: el navegador puede enviarla ya rellena, y cada proxy por el que pasa la petición añade al final la IP real de quien se conectó a él. Los primeros valores los ha escrito el cliente y puede inventárselos; el último lo ha escrito nuestra propia infraestructura. Un limitador que lea el primero se desactiva solo: basta con mandar una IP falsa distinta en cada petición para no alcanzar nunca el límite. Pekke lee el último segmento.

Los limitadores fallan abiertos, y es una decisión consciente con su contrapartida escrita: si el almacén que lleva la cuenta no responde, la petición pasa en lugar de bloquearse. Un limitador está para encarecer el abuso, no para convertirse en un punto único de fallo. Preferimos absorber un pico de peticiones raras antes que dejar a una familia entera sin poder reservar porque un contador está caído.

Hay trabajo que no debe vivir en el proceso que sirve las páginas: mandar correos, ir a buscar los datos de una tienda, reaccionar a un cambio en la base de datos. En Pekke eso son Edge Functions escritas en Deno y desplegadas junto a la base de datos. Deno exige permisos explícitos de red y de entorno, las claves de servicio se quedan ahí y nunca se acercan al navegador, y una tarea lenta —una tienda que tarda en responder— no ocupa un hueco del servidor que atiende a los visitantes.

Algunas de esas funciones las dispara la propia base de datos: cuando cambia una fila, un webhook llama a la función que corresponde. Ese endpoint está publicado en internet como cualquier otro, así que cada llamada llega con una cabecera secreta que la función verifica antes de hacer nada. Sin esa comprobación, quien diera con la URL podría fabricar eventos que la base de datos nunca emitió y provocar, por ejemplo, una tanda de correos de confirmación a gente que no ha reservado nada.