Merge pull request '[Journal de bord] tokens et authentifications' (#65) from maxonitch/jdb/Authentication into master
Reviewed-on: PGL/Clyde#65 Reviewed-by: Maxime <231026@umons.ac.be> Reviewed-by: Wal <karpinskiwal@gmail.com> Reviewed-by: LeoMoulin <leomoulin125@gmail.com>
This commit is contained in:
		
							
								
								
									
										36
									
								
								Documents/JournalDeBord/authentification.md
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										36
									
								
								Documents/JournalDeBord/authentification.md
									
									
									
									
									
										Normal file
									
								
							@ -0,0 +1,36 @@
 | 
				
			|||||||
 | 
					# 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.
 | 
				
			||||||
		Reference in New Issue
	
	Block a user