Clyde/Documents/JournalDeBord/authentification.md

# 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.