Partager une démo privée avec connexion : contrôle d'accès léger

21 juillet 2026 · jsdeck team · 5 min de lecture

Si vous avez recherché share a private demo with login, vous avez probablement besoin d'une connexion sur une app statique sans monter un serveur Node, configurer OAuth ou payer une plateforme d'auth complète. Les comptes sécurisés (API auth) 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.

Le cas d'usage : une URL publique, un public privé

Vous voulez https://my-demo.jsdeck.com dans un email client — pas un partage d'écran — mais l'app ne doit pas être visible par tout Internet. Les comptes sécurisés vous permettent de partager un lien stable tout en exigeant une connexion avant que l'UI de démo s'affiche.

Ce que sont les comptes sécurisés (API auth)

L'API auth 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 à *votre* UI de démo ou produit. Référence complète des routes : documentation Comptes sécurisés (API auth).

Routes HTTP 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 :

Method	Path	Purpose
POST	`/public/apps/{slug}/users/register`	Create account (`email`, `password` min 8 chars)
POST	`/public/apps/{slug}/users/login`	Sign in — returns `accessToken`, `expiresAt`, `user`
GET	`/public/apps/{slug}/users/me`	Current user — `Authorization: Bearer <session token>`
POST	`/public/apps/{slug}/users/logout`	Revoke session
POST	`/public/apps/{slug}/users/forgot-password`	Send reset email
POST	`/public/apps/{slug}/users/reset-password`	Complete reset with `token` + `newPassword`

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 }).

Restreindre 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'auth s'associe au datastore JSON optionnel. Après connexion, PUT des 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 lignes owner 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 éventuellement redirectPath (ex. "/reset-password") pour que le lien de reset 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'API auth ne suffit pas

L'auth jsdeck convient à email/mot de passe par app, démos restreintes 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'API auth pour le périmètre.

Workflow pratique d'aperçu client

Déployez le dernier build sur jsdeck
Ajoutez un écran minimal connexion/inscription (email + mot de passe)
Au chargement, appelez GET /users/me ; en cas d'échec, affichez uniquement le formulaire de connexion
Option A — utilisateur démo partagé : inscrivez une fois ([email protected]) et partagez ces identifiants avec le client
Option B — comptes par viewer : laissez chaque partie prenante s'inscrire avec son email à la première visite
Sauvegardez éventuellement des notes spécifiques au client dans des lignes datastore owner pour que les données restent privées par connexion

Envoyez le lien tôt ; faites tourner le mot de passe démo ou désactivez des comptes depuis votre logique app si les identifiants fuient.

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

Bon choix : démos restreintes, aperçus client, 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.

Foire aux questions

Partager une démo privée avec connexion est-il vraiment gratuit ?

Oui. jsdeck propose un hébergement statique gratuit avec HTTPS. Les comptes sécurisés (API auth) 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 identiques à 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'API auth.

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

Pas pour l'instant — email 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 comparatif pour quand une autre plateforme convient mieux.

Prochaines étapes

Explorez d'autres guides dans le hub auth visiteur
Suivez le guide de démarrage pour déployer votre première app
Consultez Comptes sécurisés (API auth) pour la doc complète des routes et OpenAPI