Partie Server - abylsenDev/AbylsenDev GitHub Wiki

INTRODUCTION

Pour l'application Abylsen, il faut un serveur. Grâce à Java et le framework Spring, créer un web service est devenu facile.

Cette application comporte les différentes logiques métiers et l'interface avec la base de données.

Le server communiquera les informations grâce au format JSON.

TECHNOLOGIES UTILISEES

Voici les différentes technologies que nous avons intégrées à la solution :

  • Spring Boot (MVC) : ce framework permet de créer un serveur avec des controllers, des interceptors... Pourquoi cette technologie ? Connaissant l'ASP.net en C# et devant apprendre le Java, j'ai décidé d'intégrer Spring Boot en MCV car l'architecture de l'application ASP et Spring Boot se ressemblent.

  • Hibernate (ORM) : ce framework permet de gérer la couche Base de données - application objet. Pour faciliter la communication entre notre application et la base de données, et pour ne pas écrire de requête SQL dans notre code, l'utilisation d'un ORM est obligatoire. Toute la couche DB est implicite.

  • Jackson : cet outil va nous permettre de convertir nos objets en JSON.

ARCHITECTURE

Architecture

C'est un projet Maven, Le GroupId du projet est "AbylsenGroup" et l'artifactId est "AbylsenApi" : <dependency> <groupId>AbylsenGroup</groupId> <artifactId>AbylsenApi</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

L'utilitaire Log4J permet à l'application de gérer l’écriture dans des fichiers "Logs". Ils se trouvent dans ce dossier : C:/AbylsenLog/

Aujourd'hui il n'existe qu'un seul fichier log. Mais le but est de dispatcher les logs dans les bon fichiers. Par exemple tout les logs qui proviennent des Interceptors , devraient se trouver dans un fichiers "Interceptors.logs". De plus il n'y a pas de gestion de date de logs.

Les différentes requêtes et réponses se trouvent dans le projet AbylsenClassLibrary. Ceci facilite la programmation d'un client. Car elle possédera tout les objets pour pouvoir communiquer avec le serveur, et sera tenu au courant des modifications. Pour pouvoir l'intégrer à un projet, il faut l'ajouter aux dépendances Maven comme ceci :

<dependency> <groupId>AbylsenDev</groupId> <artifactId>AbylsenClassLibrary</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

INTERCEPTEURS : COMMENT VERIFIER SI LA REQUETE EST VALIDE ?

Les intercepteurs sont des objets qui permette d'encapsuler la requête. Elle se compose de 3 fonctions (PostHandle, AfterCompletion et PostHandle). Les intercepteurs permettent de faire un traitement sur la requètes avant de la rediriger au Controller, et avant l'envoi de la réponse au client.

Voici un schéma qui démontre le fonctionnement d'un Interceptor :

Interceptors-Example

SECURITE

Pour sécuriser notre serveur, nous avons implémenter 2 stratégies :

  • les clés Api (API Key) : chaque client doit être en possession d'un clé API pour pouvoir communiquer avec le serveur. À chaques requêtes envoyés le serveur contrôlera le champs "apiKey" dans l'entête de la requête. Si elle n'existe pas ou ne correspond pas à une clé enregistrer en base de données, alors le serveur refusera la communication avec le client. Cette stratégie bloque les client frauduleux, qu'Abylsen n'a pas autorisé.
  • les jetons authentification (Token Id) : pour gérer les sessions utilisateurs (connections -> déconnexion) notre serveur généres des Token ID suivant le format JWT (Java Web Token). Let Java Web Token possédera toute les informations de sessions d'un utilisateur (l'email, le mot de passe, et la date de fin de session). À chaque requête que le serveur reçoit et qui demande une connexion, nous vérifions si l'utilisateur est bien connecter grâce au Token Id qui se trouve dans l'entête de la requête. Si la session est ok le serveur ttaite la requête, sinon le serveur refuse la communication. Cette stratégie permet de sécuriser les données. De plus nous pourrons à l'avenir ajouter la notion de droits utilisateurs (certaines fonctions ne pourront être utilisées que si l'utilisateur a des droits de manager, ou de consultant...).

Les stratégies sont souvent implémenter dans les Interceptors. Ceci permet de contrôler la demande avant même de rediriger la requête vers le bon Controller.

⚠️ **GitHub.com Fallback** ⚠️