Descargas protegidas con Supabase, Stripe, R2 y Cloudflare

Los productos digitales de pago necesitan una base aburrida pero importante: los compradores deben poder pagar, iniciar sesión y descargar el archivo correcto sin exponer un enlace ZIP público.

ImgKit usa un patrón simple de descargas protegidas:

1. Supabase maneja el inicio de sesión.
2. Stripe maneja el checkout.
3. La aplicación registra el acceso al producto.
4. R2 almacena los archivos privados.
5. Cloudflare Functions devuelven URL firmadas de corta duración.

Por qué importan las descargas protegidas

Si un archivo ZIP de pago vive en una carpeta pública, cualquiera con la URL puede compartirlo. Eso puede ser aceptable para muestras gratuitas, pero es débil para productos de pago.

Las descargas protegidas agregan una verificación del lado del servidor:

• ¿Quién es el usuario?
• ¿Compró este usuario el producto?
• ¿Está activo el recurso de descarga?
• ¿Puede el servidor generar una URL temporal?

El usuario sigue obteniendo una descarga normal en el navegador, pero la ruta de almacenamiento permanente no es pública.

Inicio de sesión con Supabase

Supabase le da a ImgKit una identidad de cuenta. Un comprador inicia sesión con su correo y luego el checkout y las descargas pueden vincularse a esa cuenta.

Para los primeros productos, el inicio de sesión por correo es suficiente. Los compradores no necesitan un panel complicado solo para descargar un archivo protegido.

Checkout con Stripe

Stripe maneja la sesión de pago. El comprador inicia el checkout desde el sitio, paga y vuelve a ImgKit.

Luego el servidor necesita conectar la sesión completada con el acceso al producto. Eso puede ocurrir mediante webhooks y un endpoint de sincronización de checkout, para que el comprador vea el acceso poco después del pago.

Acceso al producto

El acceso al producto debe separarse de las etiquetas de membresía genéricas. Un comprador puede poseer un producto pero no otro.

En el caso de ImgKit, el ya retirado Builder Case Study usaba su propio derecho de producto. Ese modelo aún permite que existan productos futuros sin convertir a cada comprador en un miembro de suscripción amplia.

Almacenamiento privado en R2

R2 guarda el paquete ZIP real fuera del paquete público del sitio web. El sitio no enlaza directamente al objeto de R2.

En su lugar, un endpoint de descarga verifica el acceso y solicita una URL temporal al almacenamiento.

URL firmadas

Una URL firmada otorga acceso temporal a un archivo privado. Si la URL expira después de una ventana corta, es menos útil compartirla de forma permanente.

Esto no es un DRM pesado. Es un límite práctico de entrega de pago para un MVP.

Lo que ImgKit aprendió

La página archivada de ImgKit Builder Case Study preserva las decisiones de implementación circundantes: por qué se pausó la venta de software de pago, cómo se dieron forma las descargas protegidas y cómo el paquete de código fuente se probó como primera oferta de pago.

Ese contexto importa porque el flujo técnico es solo la mitad del producto. La otra mitad es decidir qué vender primero.

Preguntas frecuentes

¿Por qué no poner los archivos ZIP de pago en una carpeta pública?

Los archivos públicos se pueden compartir directamente. La entrega protegida permite que el servidor verifique el acceso de la cuenta y devuelva URL de descarga de corta duración.

¿Stripe guarda el archivo?

No. Stripe maneja el pago. El acceso al producto y la entrega de la descarga los manejan la aplicación y el almacenamiento privado.

¿Por qué usar URL firmadas?

Las URL firmadas permiten que un archivo privado se descargue por un tiempo limitado sin exponer el acceso permanente al almacenamiento.