Visitor auth para apps estáticas: protege demos sin un backend completo

· jsdeck team · 5 min de lectura
Visitor auth para apps estáticas: protege demos sin un backend completo

Si buscaste visitor auth for static apps, probablemente necesitas login en una app estática sin montar un servidor Node, configurar OAuth ni pagar por una plataforma de autenticación completa. Las cuentas seguras (auth API) de jsdeck — también llamadas visitor auth — dan a cada app alojada sus propias cuentas de email/contraseña, tokens de sesión y filas opcionales del datastore por usuario. Esta guía explica cómo funciona, muestra llamadas API reales y es honesta sobre cuándo usar Clerk, Auth0 o un backend completo en su lugar.

Por qué las apps estáticas necesitan un modelo de auth distinto

Los tutoriales tradicionales de autenticación asumen que controlas un servidor: establecer cookies, ejecutar middleware, almacenar sesiones en Redis. Una app alojada en jsdeck son archivos estáticos en HTTPS — HTML, CSS y JS. La auth API es una capa REST alojada que tu frontend llama directamente, igual que podrías llamar al datastore. Sin express-session, sin Lambdas que desplegar.

Qué son las cuentas seguras (auth API)

La auth API de jsdeck crea cuentas seguras por app para los visitantes de tu app alojada en https://your-slug.jsdeck.com. Cada cuenta es un email + contraseña limitado a ese slug de app únicamente. Tras el registro o login, la API devuelve un accessToken — un token de sesión bearer (por defecto 7 días, del lado del servidor).

Esto no es tu login del panel de jsdeck. Las cuentas del panel despliegan y configuran apps; las cuentas seguras inician sesión en *tu* demo o interfaz de producto. Referencia completa de rutas: documentación de cuentas seguras (auth API).

Rutas HTTP de auth (resumen)

Todas las llamadas usan la base apex https://jsdeck.com/api/v1 (CORS permite *.jsdeck.com). Sustituye {slug} por el nombre de tu app:

MethodPathPurpose
POST/public/apps/{slug}/users/registerCrear cuenta (email, password mín. 8 caracteres)
POST/public/apps/{slug}/users/loginIniciar sesión — devuelve accessToken, expiresAt, user
GET/public/apps/{slug}/users/meUsuario actual — Authorization: Bearer <session token>
POST/public/apps/{slug}/users/logoutRevocar sesión
POST/public/apps/{slug}/users/forgot-passwordEnviar email de restablecimiento
POST/public/apps/{slug}/users/reset-passwordCompletar restablecimiento con token + newPassword

Especificación OpenAPI: /tenant-auth-api.yaml.

Ejemplo: login desde tu frontend estático

const API = 'https://jsdeck.com/api/v1';
const SLUG = 'your-app';

async function login(email, password) {
  const res = await fetch(`${API}/public/apps/${SLUG}/users/login`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email, password }),
  });
  if (!res.ok) throw new Error('Invalid email or password');
  const { accessToken, user } = await res.json();
  sessionStorage.setItem('sessionToken', accessToken);
  return user;
}

async function currentUser(token) {
  const res = await fetch(`${API}/public/apps/${SLUG}/users/me`, {
    headers: { Authorization: `Bearer ${token}` },
  });
  return res.ok ? (await res.json()).user : null;
}

Almacena el token de sesión como una cookie de sesión — solo HTTPS, evita registrarlo en logs. El paquete @jsdeck/toolkit envuelve registro, login y llamadas al datastore con configure({ tenantUserToken }).

Proteger una demo detrás del login (sin código de backend)

Tu bundle estático puede mostrar un formulario de login hasta que exista un token de sesión válido:

// Pseudocode — adapt to React, Vue, Svelte, etc.
const token = sessionStorage.getItem('sessionToken');

async function boot() {
  if (!token) {
    renderLoginForm({ onSuccess: (t) => { sessionStorage.setItem('sessionToken', t); boot(); } });
    return;
  }
  const user = await currentUser(token);
  if (!user) {
    sessionStorage.removeItem('sessionToken');
    boot();
    return;
  }
  renderYourApp(user); // demo visible only after auth
}

El HTML alojado sigue siendo público — decides en el código del cliente qué renderizar antes del login. Para una vista previa de cliente, crea una cuenta demo compartida o registra cuentas separadas por stakeholder.

Datos privados por usuario (filas owner)

La auth se combina con el datastore JSON opcional. Tras el login, haz PUT de registros con visibility: "owner" para que solo el token de sesión de ese usuario pueda leerlos o escribirlos — la clave store_ compartida no puede. Las listas omiten las filas owner a menos que la petición incluya un token de sesión válido. Consulta la documentación de filas owner para usar la clave del datastore junto con un token de sesión.

Restablecimiento de contraseña

Llama a forgot-password con el email del usuario y opcionalmente redirectPath (p. ej. "/reset-password") para que el enlace de restablecimiento abra en tu app alojada. Tu página de restablecimiento lee ?token= de la URL y hace POST a reset-password con newPassword. Usa reset-password/status?token= para mostrar «enlace expirado» antes de pedir una nueva contraseña.

Límites y cuándo la auth API no basta

La auth de jsdeck encaja para email/contraseña por app, demos restringidas y filas JSON con alcance owner. No incluye login social/OAuth, MFA, SAML/SSO, roles de organización, logs de auditoría ni certificaciones de cumplimiento. Las apps tienen un límite de 5.000 cuentas seguras por app — suficiente para demos y productos pequeños. ¿Necesitas inicio de sesión con Google, SSO empresarial o RBAC granular? Usa Clerk, Auth0 o Supabase Auth y mantén jsdeck solo para alojamiento estático. Consulta qué cubre la auth API para detalles de alcance.

Activar y publicar

  1. Despliega tu build estático en jsdeck
  2. Activa el datastore en el panel si necesitas datos guardados o por usuario
  3. Añade una interfaz de login/registro que llame a las rutas de auth API anteriores
  4. Restringe tu interfaz principal hasta que GET /users/me tenga éxito
  5. Lee la guía completa de auth API para flujos de restablecimiento y helpers del toolkit

Para quién es esto, y cuándo no usar la auth de jsdeck

Buena opción: demos restringidas, vistas previas de clientes, apps de hackathon, MVPs y JSON por usuario mediante filas owner.

No es adecuado: login solo OAuth, requisitos MFA, SSO empresarial, roles complejos o cargas de identidad reguladas — usa Clerk, Auth0 o Supabase Auth en su lugar.

Preguntas frecuentes

¿Visitor auth for static apps es realmente gratis?

Sí. jsdeck ofrece alojamiento estático gratuito con HTTPS. Las cuentas seguras (auth API) y el datastore opcional están incluidos para la escala típica de demos y proyectos personales — sin tarjeta de crédito para empezar.

¿Las cuentas seguras son lo mismo que mi login del panel de jsdeck?

No. Tu cuenta del panel despliega apps en jsdeck.com. Las cuentas seguras son usuarios finales que inician sesión en *tu* app en your-slug.jsdeck.com mediante la auth API.

¿Pueden los visitantes iniciar sesión con Google o GitHub?

Hoy no — solo email y contraseña. Para login social o SSO, usa un proveedor de identidad dedicado. Consulta qué cubre la auth de jsdeck y el hub de comparaciones para saber cuándo encaja mejor otra plataforma.

Próximos pasos

Sobre el autor

El equipo de jsdeck escribe guías prácticas para desplegar aplicaciones JavaScript estáticas. Enviar comentarios.

¿Listo para desplegar?

Publica tu app estática en una URL en vivo en minutos — alojamiento gratuito con almacén de datos y autenticación de visitantes opcionales.

Empezar gratis