Documentation
SDK client
Session et stockage

Session et stockage

Après une connexion réussie, le SDK conserve la session dans le navigateur afin que l'utilisateur n'ait pas à se reconnecter à chaque chargement de page.

Les clés privées déverrouillées de l'utilisateur ne quittent jamais le navigateur : elles sont stockées sur l'appareil et ne sont jamais envoyées aux serveurs Secrecy, qui ne les détiennent que verrouillées.

Ce qui est stocké

Quatre entrées sont écrites par le SDK :

CléContenu
secrecy.user_app_sessionL'identifiant de session de l'application
secrecy.identitiesLes identités auxquelles l'utilisateur a accès
secrecy.key_pairsLes paires de clés utilisées pour chiffrer
secrecy.jwtLe JWT de l'application

Restaurer le client au chargement de la page

La fonction getSecrecyClient reconstruit un client à partir de ces entrées. Il retourne null si rien n'a encore été stocké, ce qui indique qu'il faut démarrer une connexion avec login.

auth.ts
const restoreClient = async (): Promise<SecrecyClient | null> => {
  // La bibliothèque de cryptographie doit être prête avant de lire les clés stockées
  await setup();
 
  const client = getSecrecyClient();
 
  if (!client) {
    // Rien de stocké, l'utilisateur doit se connecter
    return null;
  }
 
  return client;
};

Conserver la session uniquement pour l'onglet

Par défaut, les identifiants sont écrits dans le localStorage et survivent donc à un redémarrage du navigateur. Passez session: true pour utiliser le sessionStorage à la place : la session est alors perdue à la fermeture de l'onglet.

auth.ts
const restoreTabClient = async (): Promise<SecrecyClient | null> => {
  await setup();
 
  // Lire les identifiants depuis le sessionStorage au lieu du localStorage
  return getSecrecyClient({ session: true });
};
⚠️

La même valeur de session doit être passée à login et à getSecrecyClient, sinon le client est cherché dans le mauvais stockage.