Version du 21 janvier 2019 à 10:54

Présentation générale

Conception et développement d'un système de gestion d'un réseau de capteur.

Description

Notre projet s'inscrit dans le cadre d'un projet de recherche à l'IRCICA sur un réseau de capteurs à large échelle (100 noeuds). Face à un réseau de cette ampleur, il est intéressant de développer une solution de maintenance à distance de ce réseau. Il sera bien plus aisé pour les chercheurs de tester leurs hypothèses en déployant rapidement leurs logicielles sur tout ou une partie des noeuds disponibles grâce à des fonctionnalités telles que la sélection d'une partie du réseau ou encore la mise à jour d'un ensemble de capteurs de même type / architecture.

Objectifs

L'objectif de notre travail consiste pour cela à développer simultanément le front-office et le back-office. La partie front sera réalisée en utilisant les technologies web classiques. La partie back-end sera constituée d'un ensemble de webservices en différents langages permettant la communication réseau et la gestion d'une base de données de noeuds et capteurs. Il faudra y développer des services classiques comme la gestion des utilisateurs et des services spécifiques (compilation du code source, téléchargement à distance du logiciel sur les noeuds). La partie front-end aura vocation à être utilisée par des utilisateurs externes au projet et devra donc être ergonomique et facile de compréhension. Elle devra également être fonctionnel et modifiable facilement.

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

Matériel

• Un Serveur dédié accueillant l'ensemble des services
• Un réseau de capteurs orchestré par des Raspberry Pi

Logiciel

• Ansible pour faciliter le déploiement des binaires sur les noeuds
• La plateforme Java EE pour la partie back-end couplé au framework Spring
• Une base de données PostgreSQL dans un premier temps pour assurer la persistance des données
• Une partie front-end moderne basée sur le framework Vue.js et sur un framework CSS tel que Bootsrap, Semantic UI ou Foundation pour ne citer que les plus connus

Liste des tâches à effectuer

• Comparaison et documentation sur les frameworks web de création d'interface (Angular, React, Vue ...)
• Documentation sur Spring et Java EE en général
• Configuration des routes du projet Spring (racine, connexion dans un premier temps)
• Création d'une interface utilisateur (front-end)
  • Page de connexion pour commencer
• Implémentation d'un gestionnaire d'utilisateurs
• Création d'une base de données pour gérer les noeuds
• Implémentation du service d’envoi des fichiers de mise à jour

Calendrier prévisionnel

Réalisation du Projet

Premier semestre

Comme pour tout début de projet, nous avons passé une bonne partie de cette semaine à nous documenter et à évaluer des solutions potentielles. Le monde du front-end évoluant rapidement, il n'est pas toujours facile de s'y retrouver et de faire les choix adéquats. En l'occurrence, nous avons comparé les trois solutions qui sont Angular, React et Vue pour concevoir une interface web dynamique et moderne. Notre choix s'est finalement porté sur le framework Vue.js pour les raisons suivantes :

• Une prise en main rapide : sans même avoir suivi un cours spécifique à Vue.js, le choix pertinent des mot-clés aide la compréhension
• Des performances supérieures à ses concurrents sur bien des aspects
• Sa légèreté principalement causée par son fonctionnement par plugins

Concernant le framework CSS, nous avons fait simple et avons choisi Bootstrap, un standard du web depuis quelques années et qui reste d'actualité face à des alternatives en vogue telles que Foundation ou Semantic UI. Les classes proposées par ces feuilles de styles se démarquent quasi-exclusivement par la pâte graphique qu'elles apportent et non par les technologies employées qui sont identiques.

Avec ces outils en main, nous avons commencé par créer la page sur laquelle l’utilisateur arrivera s'il n'est pas déjà enregistré, la page de connexion. Rien de particulier sur cette page, un champ pour le login et un pour le mot de passe. Nous allons tout de même ajouter un peu de dynamisme en affichant un message d'erreur en d'échec de la connexion pour mauvais login ou mot de passe.

En parallèle, nous nous sommes intéressés à Spring et de manière plus générale à Java EE. Pour pratiquer et prendre ce vaste écosystème en main, nous avons créé quelques projets avec Spring comme une API REST basique ou encore un controller plus classique capable de servir des pages web statiques. Une fois cette étape de découverte effectuée, nous sommes rentrés dans le vif du sujet. L'idée dans un premier temps et de concevoir le gestionnaire d'utilisateurs et de prouver son fonctionnement en affichant le login de la personne enregistrée sur une page d'accueil. Pour ce faire, nous avons parcouru quelques projets existants sur Internet afin d'avoir une idée de la structure globale des projets de plus grande taille et également pour identifier les outils que nous allons devoir utiliser. En cette fin de première semaine, nous avons un bon aperçu des bibliothèques et frameworks que nous allons utiliser. A titre d'exemple, nous pensions devoir implémenter nous même le système de session et donc gérer les cookies émis et reçus mais il s'est avéré que Spring dispose d'un framework nommé Spring Security qui fournit des fonctionnalités d’authentification et d'autorisation pour les applications web. Les objectifs de la semaine suivante seront de se renseigner sur ce framework, de pratiquer l'utilisation d'une base de données et finalement d'associer ces travaux pour stocker des utilisateurs dans la base et permettre l'accès à une page sécurisée au moyen d'un formulaire de connexion.

Durant cette deuxième semaine nous avons décidé de reprendre les bases de Spring pour mieux comprendre le fonctionnement des dépendances utilisées. Notamment, nous nous sommes concentrés sur la communication avec une base de données en ProgreSQL via la Java Persistence API (ou JPA) couplée à l'interface Java Database Connectivity (JDBC) qui permet justement de communiquer avec une base de données, quelque soit le type (MySQL, PostgreSQL). Plus précisément, JPA permet de s'affranchir des créations de tables, de l'ajout et des modifications dans celles-ci. Il est également possible de faire des requêtes en JPQL, un langage proche de SQL mais orienté objet. Ce qu'il faut retenir de tout ça c'est que cette API va nous permettre de définir des classes vu comme des entités dans le projet et qui serviront à créer et remplir une table de données.

Grâce à ces recherches que nous avons effectuées, nous avons maintenant une meilleur idée du squelette du projet. Ainsi, pour un projet comme le nôtre il sera nécessaire d'avoir :

• Pour la base de données :
  • une classe par table de données
  • une classe qui permet à la JPA d’interagir avec la première classe décrite comme une table
  • un fichier application.properties pour indiquer au projet la localisation de la BDD et les identifiants pour y accéder

• De manière général pour un projet Spring Boot :
  • une classe pour gérer les routes de notre site Web (et donc les requêtes, qu'elles soient de type GET ou POST)
  • le fichier pom.xml dans le cas de l'utilisation de Maven pour spécifier la liste des dépendances
  • des fichiers de ressources comme des .html pour afficher les informations nécessaires à l'utilisateur
  • une classe Application qui permet de lancer l'application depuis le projet (il sera ultérieurement utile d'utiliser une exportation en Jar ou War pour utiliser le projet de manière indépendante)

Pour la suite du projet il est également nécessaire d'intégrer le framework Spring Security qui permet justement de gérer l'accès à différentes pages. Il est possible d'utiliser ce framework sans base de données mais il serait compliquer dans ce cas d'assurer la persistance en mémoire des utilisateurs et des rôles qui leur sont associées. Il va donc être important de faire interagir le framework Spring Security avec la base de données.

Commit 1 et 2

Intitulé : "Projet Spring Boot avec gestion de base données simple et interface web pour l'ajout d'utilisateurs avec affichage des clients ajoutés"

Ce commit utilise les connaissances que nous avons acquis sur l'utilisation des bases de données. Ce projet utilise l'outil de gestion d'automatisation de production Maven et a les dépendances suivantes :

• Spring Boot
• JPA pour la gestion des bases de données externes, dans notre cas
• Thymeleaf, un moteur de template

Il permet d'accéder à une page d'accueil qui demande à un utilisateur (quelconque pour le moment mais par la suite il devra être Admin) d'ajouter des utilisateurs à la base de données. Lorsque le bouton est pressé, les informations (pseudo et mot de passe) sont passés dans le corps d'une requête POST. Coté Java, une méthode permet de gérer les requêtes POST de cette page. Pour le moment, nous créons un objet "Customer" en lui affectant le pseudo et le mot de passe rentré par l'utilisateur. Grâce ) la méthode save fournie par notre objet CustomerRepository, nous faisons persister ces informations en base de données. Enfin, nous effectuons une redirection sur la page du formulaire avec un paramètre "ok" pour avertir du bon enregistrement. Ainsi, quand le navigateur effectuera son GET, il ajoutera "?ok" à la destination permettant donc à la template Thymeleaf grâce à une condition d'afficher un message.

Pour le commit 2, nous avons souhaité vérifier si le pseudo entré dans le formulaire n'est pas déjà présent dans la base de données. Pour ce faire, nous avons au niveau du traitement du POST ajouté quelques lignes qui vont faire une requête à la BDD. Si le résultat est "null", tout se passe comme précédemment. Dans le cas contraire, la redirection est effectué sur le formulaire avec comme paramètre "?error". Une autre condition dans la vue permet de gérer ce cas d'erreur.

Commit 3

Intitulé : "Restructuration du site web avec une page d'accueil, de login et d'ajout d'utilisateur et ajout de Spring Security pour l'instant pas opérationnel"

Nous avons implanté la possibilité d'ajouter des utilisateurs avec le rôle Admin pour l'instant. En se rendant sur la page "registration", il est ainsi possible d'ajouter un utilisateur avec un mot de passe. Le serveur vérifie que le pseudo de l'utilisateur n'existe pas avant de l'ajouter. Un message permet d'indiquer à l'administrateur si l'utilisateur a bien été ajouté ou s'il existe déjà.

Les pages ont également été remaniées afin de parfaire l'expérience de la navigation. Spring Security a également été ajouté même si pour le moment il ne fonctionne pas. En effet, on indique au framework que la page login est celle à utiliser pour vérifier l'utilisateur. On indique également que seul un utilisateur avec le rôle Admin peut se connecter à la page d'ajout d'utilisateurs.

Enfin, grâce à des requêtes JPQL on précise quels sont les paramètres de la base de données à utiliser pour identifier l'utilisateur qui essaie de se connecter. L'enregistrement d'utilisateurs fonctionne mais pour l'instant l'entrée du rôle "ADMIN" est dupliquée ce qui sera à corriger.

Commit 4

Intitulé : "Front-end : page de login et page d'accueil"

La page de login n'a pas changé depuis la semaine, elle a juste été ajoutée au Git. Néanmoins, nous avons travaillé sur une ébauche de la page de d'accueil, la page qui s'affichera après que l’utilisateur se soit enregistré.

Dans l'ordre, on y voit un header en haut de la page qui permettra de se déconnecter ainsi qu'un autre lien qui affichera une page de configuration avec notamment la possibilité pour un Admin de d'ajouter un utilisateur et de lui affecter un rôle. Plus bas, il s'agit d'un tableau ou chaque ligne représente un nœud avec ses informations. Il ne s'agit ici que d'un exemple, tant pour le choix des informations qui seront affichées que pour le contenu actuel des lignes. Ce tableau utilise le plugin DataTables pour jQuery et offre des fonctionnalités prêtes à l'usage comme le tri par colonne, la recherche ou encore la sélection de ligne. A ce propose, pour le moment quand des lignes sont sélectionnées ou désélectionnées, un message s'affiche dans la console avec le contenu de la ligne, montrant ainsi qu'il est possible de les recueillir.

La seconde partie de cette page concerne l'upload d'un fichier. Il sera possible prochainement de déposer un fichier dans la zone ou de cliquer dessus pour choisir un fichier dans l'explorateur. La barre de progression montrera après l'appui sur un bouton le pourcentage déjà transféré. Ce bouton n'est pas encore présent mais sera très probablement situé au dessous de la zone d'upload.

L'objectif sera de communiquer le fichier au serveur non pas seul mais avec des métadonnées (liste des nœuds concernés), ce qui fait une potentielle difficulté pour cette étape.

Commit 5

Intitulé : "Spring Security Opérationnel"

Dans l'état actuel du projet, tout le monde peut se créer un compte et se connecter au site avec et la page d'accueil affiche le pseudo de l'utilisateur. Lorsque l'utilisateur n'est pas connecté, toutes les requêtes le renvoient vers la page de login. D'un point de vu quantité de lignes, peu de changements majeurs ont été apportés par rapport au commit 3. En effet, les dysfonctionnements étaient plutôt causés par des éléments de configuration et plus précisément ces 2 points :

• La classe Customer doit pour être reconnu comme un utilisateur par Spring Security posséder un attribut "active" de type entier valant 0 ou 1.
• Ensuite, un changement a eu lieu dans la dernière version de Spring Security. Le mot de passe d'un utilisateur doit être par défaut haché avec Bcrypt dans la base de données. Apporter une telle sécurité nous paraissait futile durant cette phase d'apprentissage du framework mais finalement, il s'est avéré que de laisser des mots de passe en clair demande plus de configuration. Nous avons donc utilisé Bcrypt.

Pour terminer cette partie consacrée à la gestion des utilisateurs il va falloir travailler sur les points suivants :

• Fixer un utilisateur admin en BDD
• Autoriser la création de comptes seulement aux admins
• Créer un rôle utilisateur avec moins de privilèges (création de comptes)

Commit 6 et 7

Intitulé : "Upload d'un fichier"

On continue toujours parallèlement le développement de la partie front. Ce commit intègre la possibilité d'envoyer un fichier unique associé à une liste de nœuds via une requête POST. Après avoir pris connaissance des événements écoutables au niveau de l'action de drag & drop, nous avons fait en sorte d'afficher le nom du fichier dans le cadre une fois celui-ci déposé. Dans une optique d'interactivité, nous avons fait en sorte que la bordure de la zone s'épaississe quand un fichier survole la zone. Pour stocker les données qui seront envoyées, nous avons utilisé l'objet FormData qui permet de construire un ensemble de paires clé / valeur qui représenteront les données que nous enverrons. L'avantage étant que cet objet peut être envoyé via la méthode send() de l'objet XMLHttpRequest. Ainsi au moment de l’événement "drop", nous stockons le nom du fichier et l'objet "File" qui sera converti en binaire à l'envoi. Lorsque l'utilisateur déposent plus d'un fichier dans l'espace prévu, un pop-up d'avertissement apparaît pour indiquer qu'un seul fichier ne peut être transféré.

Nous avons ensuite ajouté la possibilité de cliquer sur cette zone pour choisir le fichier dans l'explorateur. Pour ce faire, nous avons rendu invisible via le CSS un input de type file. En JS, nous observons l’événement "click" sur la zone de dépôt puis nous simulons un clic sur le input invisible faisait apparaître la fenêtre de l'explorateur. Un autre événement "change" sur l'élément input permet de recueillir le fichier et ses infos.

Il a fallu également s'attaquer aux quelques cas d'usage particuliers comme lorsque que l'utilisateur dépose ou choisi un nouveau fichier. Pour ce cas, nous avons fait le choix de remplacer le fichier existant par le nouveau.

Avant de procéder à l'envoi, il faut récupérer la liste des nœuds sélectionnés et pour ce faire, nous avons créé un "Set" qui sera passé intégré à notre instance de FormData grâce la méthode append() de cet objet.

Enfin, pour procéder à l'envoi, il suffit de cliquer sur le bouton en bas de page. Si aucun nœud n'a été sélectionné ou si aucun fichier n'a été fourni, un pop-up apparaîtra pour stipuler l'erreur. En revanche si tout se passe bien, la requête POST peut être envoyée. Dernière petite fonctionnalité, XMLHttpRequest nous permet de récupérer le nombre d'octets total à transmettre ainsi que le nombre déjà transmis ce qui est parfait pour intégrer une barre de progression. Une fois le transfert opéré, un message apparaît et la page est rechargée.

https://projets-ima.plil.fr/mediawiki/images/3/35/Dropfile.gif

Commit 8

Intitulé : "Optimisation de la communication avec la BDD"

Pour ce commit, nous nous sommes concentré uniquement sur la base de données et ses interactions avec Spring. Premièrement, grâce au fichier data.sql il est possible d'ajouter des entrées au lancement du serveur. Le problème étant qu'ensuite, lorsqu'on ajoute un utilisateur depuis le site internet, Spring commence par l'id '1' pour l'utilisateur alors qu'il est déjà utilisé vu que des utilisateurs ont été entrés dans la base de données au lancement. Pour corriger ce problème, il est nécessaire de modifier la manière dont Hibernate va générer les id. En fait, on précise dans notre classe "Customer" que la génération est en mode automatique alors qu'il faut en fait la paramétrer.

Malgré toutes les tentatives sur les différents type de génération, nous ne sommes pas parvenu à changer dynamiquement la valeur initial de l'id. Nous avons donc choisi d'utiliser une méthode setId() qui va être appelée en même temps que setPassword() et setPseudo(). Nous utilisons la méthode count() déjà implémenter dans JpaRepository (et donc CrudRepository). Celle-ci permet de connaître le nombre d'entrées dans la base de données à chaque fois que la requête "registration" est émise. L'assignation de l'id est donc dynamique.

L'erreur qui dupliquait le champ "ADMIN" a également été corrigée. Plutôt que de créer un nouvel utilisateur à chaque requête vers "registration", on recherche le rôle "ADMIN" dans la table rôle et assigne la ligne trouvé à l'utilisateur. Enfin, nous avons ajouté un utilisateur par défaut : pseudo : user / password : user, et un administrateur par défaut : pseudo : admin / password : admin.
Remarque : il est obligatoire de stocker le password haché dans le fichier data.sql pour que Spring puisse l'utiliser (en effet, depuis Spring Boot 5.0, il est obligatoire d'encoder le mot de passe).

Commit 9

Intitulé : "Routage du site"

Nous avons implémenté la distinction entre un utilisateur classique et un administrateur. Les pages auxquelles peut accéder chaque rôle sont donc différentes : seul l'administrateur peut accéder à la page "registration"; les deux utilisateurs doivent se connecter pour accéder aux différentes pages du site. L'administrateur peut désormais préciser quel rôle aura l'utilisateur ajouté
Les templates sont également codés pour n'afficher que les informations dédiées au rôle qui est connecté au site internet.

Commit 10

Intitulé : "Intégration du front au projet"

Ce commit consiste en l'intégration de la partie front au projet. Pour que les templates puissent utiliser les ressources dont elles ont besoin (CSS et JS), nous avons créé un dossier static contenant deux autres dossiers JS et CSS pour lesquels nous avons autorisé l'accès à tout le monde dans la configuration de Spring Security. Pour la page de login, aucun changement majeur si ce n'est la présence d'un message d'erreur qui s'affiche lorsque que le compte n'existe pas. Son apparition ou non est gérée dans la template Thymeleaf grâce à une condition sur le paramètre "erreur" de l'URL.

La page d'accueil a elle aussi été mise à jour. Seul les liens "déconnexion" et "paramètres" de la barre de navigation ont été changés. Des tests sur mobile, nous ont révélé quelques soucis d'adaptation du contenu, il faudra veiller à régler ces petits défauts d'affichage. Il serait intéressant également de travailler sur la template "registration" consacrée à l'ajout d'utilisateurs. Enfin, il faudra être capable au niveau du controller Spring de récupérer le fichier envoyé depuis l'interface via la requête POST.

Commit 11

Intitulé : "Sauvegarde des fichiers envoyés"

Ce commit ajoute l'enregistrement du fichier uploadé depuis l'interface web. Ce fichier se retrouve stocker dans un répertoire nommé <pseudo>_<timestamp> qui lui même est dans le dossier files. Ceci permet d'avoir un dossier unique pour chaque envoi de fichier par l'utilisateur tout en gardant une trace de son nom pour d'éventuels futurs besoin. Techniquement, la sauvegarde du fichier s'effectue en copiant par bloc de 1024 octets le binaire contenu dans la requête vers sa destination au moyen des flux Java. Pour la suite nous avons envisagé la création d'un programme annexe daemon dont le but serait de scruter la présence de nouveaux fichiers et de les transférer sur les nœuds concernés. Cette liste de nœuds sera dès le prochain commit incluse dans le dossier du fichier. On peut ensuite imaginer l'utilisation d'Ansible pour faciliter le déploiement du binaire sur les nœuds.

Commit 12

Intitulé : "Amélioration du front-end"

Nous avons ajouté une page permettant de visualiser tous les utilisateurs enregistrés sous la forme d'un tableau avec leur ID, leur pseudo et leur rôle. Cette liste n'est accessible qu'aux administrateurs.

Ajouter images

Commit 13 et 14

Intitulé : "UI : modifications mineures"

• Changement de quelques textes
• Mieux adapté aux mobiles : quelques ajustements sur le CSS ont été faits pour améliorer l'expérience sur les appareils mobiles.
• Ajout des alertes pour la page d'ajout des utilisateurs : une alerte s'affiche si le pseudo est déjà utilisé.
• Corrections orthographiques

Commit 15

Intitulé : "Passage de pseudo à email pour les utilisateurs"

Les utilisateurs sont maintenant caractérisés par leur email et non plus par leur pseudo suite à la demande de nos encadrants. Quelques ajustement au niveau des formulaires ont du être faits.

Commit 16

Intitulé : "Ajout d'une classe qui contiendra les paramètres d'une mise à jour si l'utilisateur souhaite la stocker"

Il nous a également été demandé de revoir le système permettant d'uploader des fichier depuis l'interface. L'idée est de séparer l'upload du déploiement et ainsi de pouvoir garder un historique des mises à jour qui ont été faites par chaque utilisateur afin qu'il puisse facilement réitérer ces précédentes actions.

Commit 17

Intitulé : "Implémentation de l'ajout de maj"

Nous avons désiré ajouter la possibilité d'enregistrer les paramètre d'une mise à jour; c'est à dire les noeuds connectés, le nom de la mise à jour, sa date d'exécution et le fichier binaire à téléverser. Nous avons donc implémenter une nouvelle classe Maj.java ainsi que son dépôt MajRepository.java qui va permettre de créer une nouvelle table maj. La table maj a en fait le même comportement que la table de rôle : elles possèdent toutes les deux une jointure multiples associé à la table customer.

Ensuite, nous avons écrit une page HTML basique permettant de tester cette classe maj et son bon fonctionnement en ce qui concerne les ajouts en BDD et la liaison à l'utilisateur qui l'a créé. Par la suite, nous avons pour objectif de faire évoluer la gestion des utilisateurs par une gestion par groupes. En effet, il y a plusieurs groupes de recherche dans un laboratoire mais chaque individu d'un même groupe doit avoir accès aux mises à jour du groupe. Il faudra donc créer une classe Group.java qui sera en jointure avec la table customer et la classe maj. Ainsi les mises à jour seront visibles par tous les utilisateurs d'un même groupe de recherche.

Commit 18

Intitulé : "Page home restructurée et fonctionnelle"

Nous avons enlevé le tableau des noeuds sur la page d'accueil. Elle ne comprend maintenant plus que l'espace permettant d'uploader des fichiers sur le serveur.

Commit 19 et 20

Intitulé : "Mise à jour front et sauvegarde d'une configuration"

Intitulé : "Choix du fichier pour la sauvegarde d'une configuration"

Nous avons créé une nouvelle page "Paramétrer une mise à jour" découpée en deux sections. La première est un historique des mises à jour que l'utilisateur a décidé de sauvegarder. Il aura la possibilité de sélectionner l'une d'entre-elle et de relancer son déploiement. La seconde partie concerne justement la création d'une mise à jour. L'utilisateur sélectionne les noeuds concernés, entre un nom pour cette configuration, sélectionne le fichier dans la liste, entre la date (éventuellement l'heure ?) à laquelle il veut que la mise à jour soit effectuée et enfin il choisit via les deux boutons s'il veut sauvegarder cette configuration ou seulement l'appliquer sans la sauvegarder.

Ajouter images

Le bouton "Lancer la mise à jour" n'a pour l'instant aucun impact mais nous avons réfléchi au fonctionnement de la partie back-end pour mettre en place cette action. Lors de l'appuie, nous allons créer un fichier dans un dossier prévu pour les mises à jour, supposons un qu'il s'appellera "todo". Ce fichier contiendra l'ensemble des métadonnées qui ont été entrées par l'utilisateur et pour limiter l'espace disque le chemin vers le fichier à déployer. Ce fichier pourra être dans un format de représentation des données tels que JSON ou YAML bien que cela ne soit pas forcément nécessaire. Un autre programme (en Java par exemple) se chargera de scruter ce dossier pour voir si des mises à jour sont dans l'attente d'être faites.

Commit 21

Intitulé : " Ergonomie du site"

Suite aux différentes remarques d'un de nos encadrants, nous avons revu quelques éléments de la partie front-end. Il s'agit principalement d'un changement au niveau du header où le bouton pour se déconnecter est maintenant plus visible sur la droite. Nous avons également profité pour faire un peu de nettoyage et d'organisation dans les fichiers.

Commit 25

Intitulé : "Fichier de configuration YAML"

Dans le but de ne jamais devoir modifier le code source ou encore de devoir modifier la base de données, nous avons mis en place un fichier de configuration au format YAML qui permet dans l'état actuel des choses de créer le premier utilisateur ADMIN de l'application en renseignant son email et son mot de passe. Les lignes qui suivent sont consacrées à l'établissement de la liste des nœuds qui seront visibles depuis l'interface.

adminEmail: pfe@pfe.fr
adminPassword: pfepfe
nodes:
   - name: AT-001 
     ip: '85.10.201.246'
     arch: ARM
   - name: AT-002 
     ip: '85.10.201.247'
     arch: ARM
   - name: AT-003 
     ip: '85.10.201.248'
     arch: ARM
   - name: ATTTT-004 
     ip: '85.10.201.249'
     arch: ARM 

On constate ici un objet nodes comprenant lui même une liste d'autres objets décrivant les informations relatives aux noeuds (nom, ip, architecture). La présence de ce fichier YAML est obligatoire pour garantir le fonctionnement de l'application. Sa lecture s'effectue au sein d'une classe possédant une méthode init() avec une annotation @PostConstruct qui lui permet de s’exécuter au démarrage du programme après toutes les inutilisations opérées en interne et qui sont nécessaires. Afin de parser ce fichier, nous avons utilisé la bibliothèque SnakeYAML qui possède la particularité intéressante (sûrement comme d'autres) de faire correspondre une classe avec un YAML. On aurait ici pour illustrer, une classe YAMLConf par exemple avec comme attributs String adminEmail, String adminPassword et List<NodeYAML> nodes. Il faudrait ensuite créer la classe NodeYAML de la même façon. Avec les getters/setters qui vont avec, on dispose donc d'un objet Java représentant notre fichier YAML.

Commit 26

Intitulé : "Modifications front-end"

A nouveau, nous avons effectué quelques changement en terme d'apparence. Le header se retrouve un peu plus resserré vers le centre et est maintenant pourvu d'un logo permettant de revenir à la page d'accueil. A ce propos, une vraie page d'accueil a fait son apparition car jusqu'à présent il s'agissait de la page d'upload. Cette nouvelle vue accueille selon le rang de l'utilisateur les fonctionnalités auxquelles il a accès avec une courte description.

Ajouter images

Commit 27

Intitulé : "Changement pour la configuration du réseau"

Comme nous l'avions vu dans le commit 25, la configuration du réseau se faisait au moyen d'un fichier YAML à venir déposer à la racine de l'application. Seulement, après discussion, nous avons trouvé plus judicieux de proposer cette fonctionnalité depuis l'interface web pour limiter le plus possible les interactions directes avec le serveur. De plus, cela permet à tous les administrateurs de changer cette description des noeuds (il conviendra de rediscuter avec nos encadrants d'un rang spécial éventuellement). L'upload de ce fichier s'effectue sur la page "Paramétrer une mise à jour" où un champs permet de sélectionner le fichier voulu. Un exemple est également présent juste en dessous pour montrer la syntaxe qu'il faut adopter.

nodes:
   - name: AT-001 
     ip: '85.10.201.246'
     arch: ARM
   - name: AT-002 
     ip: '85.10.201.247'
     arch: ARM
   - name: AT-003 
     ip: '85.10.201.248'
     arch: ARM
   - name: ATTTT-004 
     ip: '85.10.201.249'
     arch: ARM 

Une fois le bouton "Envoyer" pressé, la modification du réseau est visible directement dans le tableau des noeuds situé plus bas.

Ajouter images

Commit 28

Intitulé : "Bouton "Lancer la mise à jour" fonctionnel"

La page "Paramétrer une mise à jour" est maintenant fonctionnelle dans son intégralité. En effet, le bouton "Lancer la mise à jour" envoie maintenant une requête POST au serveur. Dans le cas d'une mise à jour anonyme (sans sauvegarde en BDD), toutes les informations relatives à la mise à jour sont envoyées. Dans le cas d'une mise à jour sauvegardée, seul le nom est envoyé via la requête. Coté back-end, deux nouvelles routes sont donc apparues permettant de gérer justement ces deux cas de figure. Pour le moment, les deux méthodes de ces routes se contentent de créer un fichier YAML dans le dossier toflash avec les paramètres de la mise à jour. Comme nous l'avions évoqué plus tôt, un second programme se chargera par la suite de scruter ce dossier afin de vérifier si des mises à jour doivent être effectuées.

Second semestre

Commit 29 & 30

Intitulé : "Ajout des groupes de travail"

Intitulé : "Modifications mineures"

Il existe désormais une gestion des utilisateurs et des mises à jours par groupes de travail. En effet, notre idée est que dans un laboratoire, il existe plusieurs groupes de recherche. Ainsi, il est nécessaire que un utilisateur d'un groupe de travail puisse avoir accès aux mises à jours des autres utilisateurs du même groupe. Pour cela nous avons donc créé une classe et une table "Team" (le mot-clef "group" est réservé en PostgreSQL). Celle-ci possède deux jointures multiples : une avec "Customer" pour lister les utilisateurs présents dans le groupe. La deuxième jointure est avec "Update" et remplace la jointure multiple dans "Customer" : en effet désormais les mises à jours sont par groupe et non plus par utilisateur. Dorénavant lorsqu'on accède à une "Team" on peut connaitre les utilisateurs de ce groupe et savoir les mises à jours réalisés (i.e. sauvegardé) par les utilisateurs.

A faire : il reste à ajouter un groupe par défaut pour le premier utilisateur. Nous ajouterons également la possibilité de créé de nouveaux groupes et de spécifier lors de la création d'un utilisateur, le groupe auquel il appartient.

Annexes

Ferions-nous pas une partie un peu plus générale sur des sujets qui ont moins leur place dans les rapports hebdomadaires ?

Exemples :

• Détail de la classe de configuration de Spring Security
• Détail de l'architecture du projet
• Parler de Thymeleaf

Fonctionnement du projet Spring Boot

La gestion du routage des pages internet et de l'affichage des pages internet est géré par le fichier WebMvcConfig.java. Il gère les différents appels de l'utilisateur par les méthodes POST ou GET aux pages internet, ou aux actions de boutons. Ce fichier permet également d'envoyer des informations pour que Thymeleaf les utilise et affiche des éléments dynamiquement.

Ensuite, on utilise SecurityConfig.java pour gérer les accès aux pages de données en fonction du rôle des utilisateurs.

A continuer + schema

Documents Rendus

• Gitlab : https://archives.plil.fr/aduqueno/PFE_IMA5_2018_2019_P06
• Rendu intermédiaire : Fichier:PFE 06 Rapport Intermediaire.pdf
• Rendu intermédiaire (slides) : Fichier:Slides decembre pfe06.pdf