Protéger une démo par mot de passe : accès protégé simple

Si vous avez recherché password protect an app demo, vous avez probablement besoin d'une connexion sur une app statique sans monter un serveur Node, configurer OAuth, ou payer une plateforme d'authentification complète. Les comptes sécurisés (auth API) de jsdeck — aussi appelés visitor auth — donnent à chaque app hébergée ses propres comptes e-mail/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.

« Protéger par mot de passe » sur un hébergeur statique

Les hébergeurs statiques servent les mêmes fichiers à tout le monde — il n'y a pas de porte .htpasswd côté serveur. La protection par mot de passe signifie que votre JavaScript affiche d'abord un formulaire de connexion et ne monte la démo qu'après un appel /users/login réussi qui renvoie un token de session.

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 e-mail + 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 à *votre* démo ou interface produit. Référence complète des routes : documentation Secure accounts (auth API).

Routes HTTP d'authentification (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 la 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'authentification s'associe au datastore JSON optionnel. Après connexion, enregistrez des records avec visibility: "owner" pour que seul le token de session de cet utilisateur puisse les lire ou les écrire — la clé partagée store_ ne le peut pas. Les listes omettent les lignes owner sauf si la requête inclut un token de session valide. Voir la documentation owner-row pour utiliser la clé datastore avec un token de session.

Réinitialisation du mot de passe

Appelez forgot-password avec l'e-mail 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 à e-mail/mot de passe par app, démos protégées et lignes JSON owner. Elle n'inclut pas 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 pour l'hébergement statique uniquement. Voir ce que couvre l'auth API pour les détails de périmètre.

Mot de passe unique vs démos multi-utilisateurs

Pour un ressenti « un seul mot de passe », utilisez un compte sécurisé partagé — pas une chaîne en dur dans le code source (n'importe qui peut lire votre bundle JS).

À qui s'adresse l'auth jsdeck, et quand ne pas l'utiliser

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

Mauvais usage : 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

Protéger une démo par mot de passe est-il vraiment gratuit ?

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 des démos et side projects — 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 — e-mail et mot de passe uniquement. Pour connexion sociale ou SSO, utilisez un fournisseur d'identité dédié. Voir ce que couvre l'auth jsdeck et le hub comparatifs pour savoir quand une autre plateforme convient mieux.

Prochaines étapes

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