31 lines
1.4 KiB
Markdown
31 lines
1.4 KiB
Markdown
|
# 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éssitants une
|
||
|
|
identification (permission, personelles, ...).
|
||
|
|
|
||
|
|
## Méthode
|
||
|
|
|
||
|
|
Lorsque q'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 requetes
|
||
|
|
pour identifier l'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.
|