From 204e6a9505ec85e44401fba4f04c53a83efb7999 Mon Sep 17 00:00:00 2001 From: Anthony Debucquoy Date: Thu, 7 Mar 2024 14:00:50 +0100 Subject: [PATCH 1/7] Base oauth et spring sessions --- Documents/JournalDeBord/authentification.md | 30 +++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documents/JournalDeBord/authentification.md diff --git a/Documents/JournalDeBord/authentification.md b/Documents/JournalDeBord/authentification.md new file mode 100644 index 0000000..4daceaf --- /dev/null +++ b/Documents/JournalDeBord/authentification.md @@ -0,0 +1,30 @@ +# 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. From 93144d0f90b08a5e063428987ffd6345172a37ba Mon Sep 17 00:00:00 2001 From: Bartha Maxime <231026@umons.ac.be> Date: Thu, 7 Mar 2024 15:43:16 +0100 Subject: [PATCH 2/7] added what is the token and justifications --- Documents/JournalDeBord/authentification.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documents/JournalDeBord/authentification.md b/Documents/JournalDeBord/authentification.md index 4daceaf..e0178c2 100644 --- a/Documents/JournalDeBord/authentification.md +++ b/Documents/JournalDeBord/authentification.md @@ -3,15 +3,21 @@ ## 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, ...). +(cours, informations personnelles, ...). Pour que ceux-ci puissent accomplir différentes actions nécéssitantes une +identification (permission, info 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 +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ère ASCII 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 From 7ff47b6e9cffcee0bdd53db1f83f02175a3da409 Mon Sep 17 00:00:00 2001 From: Debucquoy Anthony Date: Fri, 8 Mar 2024 19:23:59 +0100 Subject: [PATCH 3/7] wtf is it doing there ? --- frontend/src/rest/Users.js | 1 - 1 file changed, 1 deletion(-) diff --git a/frontend/src/rest/Users.js b/frontend/src/rest/Users.js index 9ca59a1..e34d611 100644 --- a/frontend/src/rest/Users.js +++ b/frontend/src/rest/Users.js @@ -6,7 +6,6 @@ export async function login(user, pass, exp){ export async function register(user, pass, mail){ return restPost("/user", {name: user, password: pass, mail: mail}); - restPost("/login", {login: user, password: pass, expiration: exp}) } /** From 1383814e34fd88760b85b24715b2e25fa7f063bf Mon Sep 17 00:00:00 2001 From: Bartha Maxime <231026@umons.ac.be> Date: Fri, 8 Mar 2024 19:57:38 +0100 Subject: [PATCH 4/7] change ASCII to ISO_8859_1 --- Documents/JournalDeBord/authentification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documents/JournalDeBord/authentification.md b/Documents/JournalDeBord/authentification.md index e0178c2..bd8debe 100644 --- a/Documents/JournalDeBord/authentification.md +++ b/Documents/JournalDeBord/authentification.md @@ -12,7 +12,7 @@ Lorsque qu'un utilisateur se connecte au serveur, nous lui envoyons un token qui 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ère ASCII aléatoires,ce qui est d'après nos recherches suffisant. +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. From 13d9020c7d900c19d89f31ed913a147f3890848a Mon Sep 17 00:00:00 2001 From: Anthony Debucquoy Date: Wed, 6 Mar 2024 22:57:01 +0100 Subject: [PATCH 5/7] stub for cursus --- frontend/src/rest/cursus.js | 41 +++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 frontend/src/rest/cursus.js diff --git a/frontend/src/rest/cursus.js b/frontend/src/rest/cursus.js new file mode 100644 index 0000000..c4cd98a --- /dev/null +++ b/frontend/src/rest/cursus.js @@ -0,0 +1,41 @@ +/** + * cursus API + */ + +import { restGet, restPost } from './restConsumer.js' + +/** + * Create a new cursus (bundle of courses) + * @param courses list of courses + */ +export async function createCursus(courses){ + return restPost("/cursus", {courses: courses} ); +} + +/** + * Delete the specified cursus + */ +export async function deleteCursus(id){ + return restDelete("/cursus/" + id); +} + +/** + * Get informations on a particular cursus + * + * @param id identification of the cursus + * + * @return list of courses + */ +export async function getCursus(id){ + return restGet("/cursus/" + id); +} + +/** + * Modify the courses of a cursus + * + * @param id the id of the cursus + * @param courses list of new courses + */ +export async function alterCursus(id, courses){ + return restPatch("/cursus/" + id, courses); +} From 8e40638b5e85e439f207a3cc2a676ecb9c8829d7 Mon Sep 17 00:00:00 2001 From: Anthony Debucquoy Date: Wed, 6 Mar 2024 23:10:29 +0100 Subject: [PATCH 6/7] adding the right dependencies --- frontend/src/rest/cursus.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/frontend/src/rest/cursus.js b/frontend/src/rest/cursus.js index c4cd98a..5aad5be 100644 --- a/frontend/src/rest/cursus.js +++ b/frontend/src/rest/cursus.js @@ -2,7 +2,7 @@ * cursus API */ -import { restGet, restPost } from './restConsumer.js' +import { restGet, restPostn, restDelete, restPatch } from './restConsumer.js' /** * Create a new cursus (bundle of courses) From a524845d06a96155d0e5bbb807b62dd8f994650c Mon Sep 17 00:00:00 2001 From: Anthony Debucquoy Date: Wed, 6 Mar 2024 19:22:10 +0100 Subject: [PATCH 7/7] First draft of the register requests api. I don't think it's currently usable but it serve as a stub for when backend will support it --- frontend/src/rest/ServiceInscription.js | 35 +++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 frontend/src/rest/ServiceInscription.js diff --git a/frontend/src/rest/ServiceInscription.js b/frontend/src/rest/ServiceInscription.js new file mode 100644 index 0000000..ee75c3b --- /dev/null +++ b/frontend/src/rest/ServiceInscription.js @@ -0,0 +1,35 @@ +/** + * functions to handle register requests. + * + * TODO: On time of writing, the backend doesn't support these endpoints so it could be modified in the future. + */ +import { restGet } from './restConsumer.js' + +/** + * create a new register requests that can be recovered by the registering service + * TODO: add info in the Object (I don't know what will be needed) + */ +export async function createRegister(){ + return restPost("/requests/register"}); +} + +/** + * list all register request in a list of Objects + */ +export async function getRegisters(){ + return restGet("/requests/register") +} + +/** + * Get info on a particular registering request + */ +export async function getRegisters(id){ + return restGet("/requests/register/" + id); +} + +/** + * Change the state of a requests. + */ +export async function validateRegister(id, state){ + return restPost("/requests/register/" + id, {state: state}); +}