Documents/JournalDeBord/authentification.md

@@ -1,36 +0,0 @@
-# Authentification
-
-## Contexte
-
-Le projet demande de pouvoir authentifier les utilisateurs présents. Le but étant de leurs associer un "contexte"
-(cours, informations personnelles, ...). Pour que ceux-ci puissent accomplir différentes actions nécéssitantes une
-identification (permission, info personelles, ...).
-
-## Méthode
-
-Lorsque qu'un utilisateur se connecte au serveur, nous lui envoyons un token qui sera stocké dans le
-navigateur. Ce token est unique à l'utilisateur et pourra être ré-envoyé dans les futures requêtes
-pour identifier l'utilisateur.
-
-Ce token est donc une chaine de 64 caractères suivant la norme ISO_8859_1(8bits par cararctère) aléatoires,ce qui est d'après nos recherches suffisant.
-
-De plus une limite de 5 token par utilisateur sera ajoutée de sorte à 
-1) S'assurer qu'une personne ne noie la base de donnée de tokens.
-2) Ajouter une protection supplémentaire pour assurer qu'un token est bien unique à un utilisateur.
-
-## Autres méthodes envisagée
-
-### Oauth2
-
-C'est un protocol d'identification vastement utilisé permettant, en plus d'identifier les requettes,
-de gérer leurs permissions. Un utilisateur créen un token peut lui attribuer des permissions
-spécifique qui restrainderaients les permissions d'utilisation de ce token. C'est très utile pour
-déployer des api de site pouvant notament être accédé par des ordinateurs / bots. Ca n'est en
-revanche pas l'objectif du projet et l'option n'a donc pas été retenue
-
-### Spring Sessions / Tomcat sessions
-
-Il aurait été possible de laisser une librairie automatiser les sessions. Malheuresement, celà
-implique de devoir se plier au format de la dite librairie. L'implémentation d'un système de gestion
-de token maison semblai à la fois, non-imposible et interessant à notre apprentisage. C'est pourquoi
-nous n'avons pas utilisé cette option.