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.