Proteger con contraseña una demo de app: acceso restringido sencillo

Si buscaste password protect an app demo, probablemente necesitas login en una app estática sin montar un servidor Node, configurar OAuth ni pagar por una plataforma de auth completa. Las secure accounts (auth API) de jsdeck — también llamadas visitor auth — dan a cada app alojada sus propias cuentas 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.
«Proteger con contraseña» en un host estático
Los hosts estáticos sirven los mismos archivos a todos — no hay puerta .htpasswd en el servidor. Proteger con contraseña significa que tu JavaScript muestra primero un formulario de login y solo monta la demo tras una llamada exitosa a /users/login que devuelve un token de sesión.
Qué son las secure accounts (auth API)
La auth API de jsdeck crea secure accounts por app para visitantes de tu app alojada en https://your-slug.jsdeck.com. Cada cuenta es un email + contraseña acotado solo a ese slug de app. Tras registrarse o iniciar sesión, la API devuelve un accessToken — un token de sesión bearer (por defecto 7 días, en el servidor).
Esto no es el login de tu panel de jsdeck. Las cuentas del panel despliegan y configuran apps; las secure accounts inician sesión en *tu* demo o UI de producto. Referencia completa de rutas: documentación Secure accounts (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:
| Método | Ruta | Propósito |
|---|---|---|
| POST | /public/apps/{slug}/users/register | Crear cuenta (email, password mín. 8 caracteres) |
| POST | /public/apps/{slug}/users/login | Iniciar sesión — devuelve accessToken, expiresAt, user |
| GET | /public/apps/{slug}/users/me | Usuario actual — Authorization: Bearer <session token> |
| POST | /public/apps/{slug}/users/logout | Revocar sesión |
| POST | /public/apps/{slug}/users/forgot-password | Enviar email de restablecimiento |
| POST | /public/apps/{slug}/users/reset-password | Completar 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;
}
Guarda el token de sesión como una cookie de sesión — solo HTTPS, evita registrarlo en logs. El paquete @jsdeck/toolkit envuelve register, login y llamadas al datastore con configure({ tenantUserToken }).
Proteger una demo tras el login (sin código 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 — tú decides en el código 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)
Auth se combina con el datastore JSON opcional. Tras el login, escribe registros con visibility: "owner" para que solo el token de sesión de ese usuario pueda leerlos o escribirlos — la clave compartida store_ no puede. Las listas omiten filas owner salvo 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 reset lee ?token= de la URL y hace POST a reset-password con newPassword. Usa reset-password/status?token= para mostrar «enlace caducado» antes de pedir una nueva contraseña.
Límites y cuándo la auth API no basta
La auth de jsdeck encaja con email/contraseña por app, demos restringidas y filas JSON owner. No incluye login social/OAuth, MFA, SAML/SSO, roles de organización, logs de auditoría ni certificaciones de cumplimiento. Las apps están limitadas a 5.000 secure accounts por app — suficiente para demos y productos pequeños. ¿Necesitas inicio con Google, SSO empresarial o RBAC granular? Usa Clerk, Auth0 o Supabase Auth y mantén jsdeck solo para hosting estático. Consulta qué cubre la auth API para el alcance.
Una contraseña vs demos multiusuario
| Enfoque | Cómo | Mejor para |
|---|---|---|
| Un login compartido | Registra una sola cuenta demo; comparte email + contraseña con revisores | Portfolio rápido o vista previa para inversores |
| Invitar registrándose | Cada visitante crea su propia secure account | Equipos de clientes, beta testers |
| Filas owner | Estado guardado por usuario tras el login | Prototipos multi-tenant |
Para una sensación literal de «una contraseña», usa una secure account compartida — no una cadena hardcodeada en el código fuente (cualquiera puede leer tu bundle JS).
A quién va dirigido y cuándo no usar jsdeck auth
Buen encaje: demos restringidas, vistas previas para clientes, apps de hackathon, MVPs y JSON por usuario vía filas owner.
No encaja: 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
¿Es realmente gratuito password protect an app demo?
Sí. jsdeck ofrece hosting estático gratuito con HTTPS. Secure accounts (auth API) y el datastore opcional están incluidos para la escala típica de demos y side projects — sin tarjeta de crédito para empezar.
¿Son secure accounts lo mismo que mi login del panel jsdeck?
No. Tu cuenta del panel despliega apps en jsdeck.com. Las secure accounts son usuarios finales que inician sesión en *tu* app en your-slug.jsdeck.com vía 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 comparativas para cuándo encaja mejor otra plataforma.
Próximos pasos
- Explora más guías en el hub de visitor auth
- Sigue la guía de primeros pasos para desplegar tu primera app
- Lee Secure accounts (auth API) para documentación completa de rutas y OpenAPI