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_session | L'identifiant de session de l'application |
secrecy.identities | Les identités auxquelles l'utilisateur a accès |
secrecy.key_pairs | Les paires de clés utilisées pour chiffrer |
secrecy.jwt | Le 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.
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.
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.