Comprendre la session
Le but de la session est de sécuriser l'accès à l'OAV via un token d'accès, puis un cookie matérialisant une session. Cette session a une durée de vie et empêche un utilisateur qui ne l'aurait pas d'avoir accès à l'OAV (dans le cas d'un partage d'URL, par exemple). La session est également sauvegardée dans le back pour vérifier qu'elle est bien valide.
Accès à l'OAV :
Le premier accès à un OAV via le token est un passage obligatoire afin d'initier un projet avec le contexte voulu. En effet, le token forgé grâce à l'API fasst-sessions permet de récupérer les informations sauvegardées directement sur l'OAV. Lorsqu'un token est fourni à l'endpoint /project (dans la requête de l'URL), un nouveau projet est initié (ou récupéré s'il existe déjà). Une fois cette mécanique réalisée, le token n'est plus utilisable, nous utilisons donc express-sessions pour que le front puisse continuer d'appeler cet endpoint uniquement avec l'ID du projet en paramètre de la requête (et le cookie de session fourni). Cette session contient également la liste des projectId pour lesquels elle a accès. Ce qui permet de s'assurer que la personne accédé bien a un project pour lequel un token a été forgé et utilisé.
Gestion du contexte :
Le contexte fourni à l'OAV est mappé dans la méthode createProject et peut être personnalisé selon les besoins de l'OAV.
Gestion du cookie :
Cette session à une durée de vie maximale et est revérifié à chaque appel à l'endpoint /project (rafraîchissement de la page, par exemple).
Pour configurer la durée, la clé d'environnement SESSION_CHECKING_MAX_AGE doit être renseignée. De plus, les sessions créées sont sauvegardées dans MongoDB et utilisent également cette clé pour les supprimer automatiquement. Dans le cas ou l'utilisateur repasse un nouveau token avec une session déjà active, la durée de la session repart de zero (pour tous les projects donc).
Désactivation de la vérification :
Il est possible de désactiver la vérification de la session en utilisant la clé d'environnement SESSION_CHECKING_DISABLED à false. Cette désactivation ne désactive pas l'accès via un token. Par contre, si un token n'est pas fourni et qu'une session n'est pas présente, un projet fictif est créé (et configurable) via le fichier getProjectFromMockCtrl.mjs. Si un projectId est fourni, l'utilisateur accède directement à ce projet sans vérification de token ou session.
Endpoints de gestion de la session :
En cas de besoin, 2 endpoints sont disponibles au niveau du serveur :
- POST /user-session : permet de rajouter un projectIdà la session en prenant le dans le body de la requête.
- DELETE /user-session : permet de supprimer un projectId (en paramètre de l'URL) de la session pour que l'utilisateur n'est pas accès a ce projet.