Auth visiteur pour apps statiques : protéger les démos sans backend complet

Si vous avez cherché visitor auth for static apps, vous avez probablement besoin d'une connexion sur une app statique sans déployer un serveur Node, configurer OAuth, ou payer pour une plateforme d'auth complète. Les comptes sécurisés (auth API) de jsdeck — aussi appelés auth visiteur — donnent à chaque app hébergée ses propres comptes email/mot de passe, tokens de session et lignes datastore optionnelles par utilisateur. Ce guide explique le fonctionnement, montre de vrais appels API, et est honnête sur quand utiliser Clerk, Auth0 ou un backend complet à la place.

Pourquoi les apps statiques ont besoin d'un modèle d'auth différent

Les tutoriels d'auth classiques supposent que vous contrôlez un serveur : définir des cookies, exécuter du middleware, stocker les sessions dans Redis. Une app hébergée sur jsdeck, ce sont des fichiers statiques en HTTPS — HTML, CSS et JS. L'auth API est une couche REST hébergée que votre frontend appelle directement, comme vous pourriez appeler le datastore. Pas de express-session, pas de Lambdas à déployer.

Ce qu'est secure accounts (auth API)

L'auth API de jsdeck crée des comptes sécurisés par app pour les visiteurs de votre app hébergée sur https://your-slug.jsdeck.com. Chaque compte est un email + mot de passe limité à ce slug d'app uniquement. Après inscription ou connexion, l'API renvoie un accessToken — un token de session bearer (par défaut 7 jours, côté serveur).

Ce n'est pas votre connexion au tableau de bord jsdeck. Les comptes tableau de bord déploient et configurent les apps ; les comptes sécurisés se connectent à l'interface de *votre* démo ou produit. Référence complète des routes : documentation Secure accounts (auth API).

Routes HTTP d'auth (résumé)

Tous les appels utilisent la base apex https://jsdeck.com/api/v1 (CORS autorise *.jsdeck.com). Remplacez {slug} par le nom de votre app :

Spécification OpenAPI : /tenant-auth-api.yaml.

Exemple : connexion depuis votre frontend statique

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;
}

Stockez le token de session comme un cookie de session — HTTPS uniquement, évitez de le logger. Le package @jsdeck/toolkit encapsule inscription, connexion et appels datastore avec configure({ tenantUserToken }).

Protéger une démo derrière une connexion (sans code backend)

Votre bundle statique peut afficher un formulaire de connexion tant qu'un token de session valide n'existe pas :

// 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
}

Le HTML hébergé reste public — vous décidez dans le code client quoi afficher avant la connexion. Pour un aperçu client, créez un compte démo partagé ou inscrivez des comptes séparés par partie prenante.

Données privées par utilisateur (lignes owner)

L'auth s'associe au datastore JSON optionnel. Après connexion, faites des PUT d'enregistrements avec visibility: "owner" pour que seul le token de session de cet utilisateur puisse les lire ou écrire — la clé store_ partagée ne le peut pas. Les listes omettent les lignes owner sauf si la requête inclut un token de session valide. Voir la doc owner-row pour utiliser la clé datastore avec un token de session.

Réinitialisation du mot de passe

Appelez forgot-password avec l'email de l'utilisateur et optionnellement redirectPath (ex. "/reset-password") pour que le lien de réinitialisation s'ouvre sur votre app hébergée. Votre page de reset lit ?token= dans l'URL et POST vers reset-password avec newPassword. Utilisez reset-password/status?token= pour afficher « lien expiré » avant de demander un nouveau mot de passe.

Limites et quand l'auth API ne suffit pas

L'auth jsdeck convient à l'email/mot de passe par app, aux démos protégées et aux lignes JSON owner. Elle n'inclut pas la connexion sociale/OAuth, MFA, SAML/SSO, rôles d'organisation, journaux d'audit ou certifications de conformité. Les apps sont plafonnées à 5 000 comptes sécurisés par app — largement suffisant pour démos et petits produits. Besoin de connexion Google, SSO entreprise ou RBAC fin ? Utilisez Clerk, Auth0 ou Supabase Auth et gardez jsdeck uniquement pour l'hébergement statique. Voir ce que couvre l'auth API pour le périmètre.

Activer et livrer

1. Déployez votre build statique sur jsdeck
2. Activez le datastore dans le tableau de bord si vous avez besoin de données sauvegardées ou par utilisateur
3. Ajoutez une UI connexion/inscription qui appelle les routes auth API ci-dessus
4. Protégez votre UI principale tant que GET /users/me n'a pas réussi
5. Lisez le guide auth API complet pour les flux de reset et les helpers toolkit

Pour qui c'est fait, et quand ne pas utiliser l'auth jsdeck

Bon choix : démos protégées, aperçus clients, apps hackathon, MVPs, et JSON par utilisateur via lignes owner.

Pas adapté : connexion OAuth uniquement, exigences MFA, SSO entreprise, rôles complexes, ou charges d'identité réglementées — utilisez Clerk, Auth0 ou Supabase Auth à la place.

Questions fréquentes

L'auth visiteur pour apps statiques est-elle vraiment gratuite ?

Oui. jsdeck propose un hébergement statique gratuit avec HTTPS. Les comptes sécurisés (auth API) et le datastore optionnel sont inclus pour l'échelle typique démo et side-project — sans carte bancaire pour commencer.

Les comptes sécurisés sont-ils la même chose que ma connexion tableau de bord jsdeck ?

Non. Votre compte tableau de bord déploie des apps sur jsdeck.com. Les comptes sécurisés sont les utilisateurs finaux qui se connectent à *votre* app sur your-slug.jsdeck.com via l'auth API.

Les visiteurs peuvent-ils se connecter avec Google ou GitHub ?

Pas pour l'instant — email et mot de passe uniquement. Pour la connexion sociale ou SSO, utilisez un fournisseur d'identité dédié. Voir ce que couvre l'auth jsdeck et le hub de comparaisons pour savoir quand une autre plateforme convient mieux.

Prochaines étapes

• Explorer d'autres guides dans le hub auth visiteur
• Suivre le guide de démarrage pour déployer votre première app
• Lire Secure accounts (auth API) pour la doc complète des routes et OpenAPI