Version du 2 octobre 2018 à 17:10

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

Semaine 1

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.

Semaine 2

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 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 la difficulté de cette étape. Après réflexion, trois solutions semblent possible pour résoudre ce problème :

• La première consiste à faire figurer dans la même requête POST, le fichier encodé en base 64 ainsi que les métadonnées. Cependant, ceci à pour effet d'alourdir les données du fichier d'environ 33% (testé sur plusieurs fichiers).
• On peur ensuite imaginer que le navigateur envoie le fichier d'une manière plus traditionnelle en multipart/form-data. Le serveur répondrait alors avec un identifiant que le client attendrait pour envoyer les méta. Le serveur serait alors en mesure d'associer le fichier et ses méta.
• La troisième solution consiste à inverser les étapes de la solution 2. D'abord les méta puis le fichier.

Evidemment, la solution la plus simple à mettre en place est la 1 mais ce choix n'est pas anodin et il faudra donc prendre le temps de creuser et d'évaluer ces solutions.

Semaine 3

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)

Annexes

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

Détails de la classe de configuration de Spring Security Détails de l'architecture du projet (image ?) Parler de Thymeleaf

Documents Rendus

• Gitlab : https://archives.plil.fr/aduqueno/PFE_IMA5_2018_2019_P06