CAW1 2015 Projet de Antonino D'Angelo et Clément Perrette

De Ensiwiki
Aller à : navigation, rechercher
Logo ensiwiki 140.jpg
Titre du projet Remote Access Security - RAS
Cadre Ensimag Projet Web 2A Alternant

Équipe Antonino D'Angelo Clément Perrette
Encadrants Sébastien Viardot


Présentation générale

Contexte

Dans le cadre de notre deuxième année à l'ENSIMAG, nous suivons un cours de Construction d'Applications Web. Ce cours aboutit à un projet de développement d'un site internet en binôme. Bien que de thématique libre, la réalisation de ce site est guidée par un certain nombre de contraintes techniques imposées, détaillées dans le cahier des charges.

Description du projet

Remote Access Security (RAS) est une application web qui permet de gérer des autorisations d'accès à une zone dans des bâtiments. On imagine que l’accès aux différentes zones se fait grâce à une carte que l'on passe sur un capteur. Le but de cette application est donc de gérer les cartes, les zones, les capteurs et bien sûr les autorisations.

Le projet devant être réalisé en temps restreint, nous avons choisi de mettre l’accent sur la découverte et l'utilisation du framework play. Certaines fonctionnalités sont donc utilisées ici, pour des aspects pédagogiques. Nous étions partis sur une version plus ambitieuse mais les contraintes de temps nous ont forcé à nous restreindre.

Cahier des charges

Le projet devra comporter les éléments suivants :

  • Utilisation d'un framework : nous utiliserons Play Framework[1]
  • Gestion des rôles avec des utilisateurs différents ayant des droits et des rôles différenciés - utilisateurs, responsables de zones, administrateurs.
  • Site adapté à plusieurs terminaux dont une version mobile - Nous utiliserons le framework CSS Materialize CSS[2].
  • Mise en place de jeux de tests unitaires : pour tester la partie modèle et contrôleur - Plusieurs tests unitaires implémentés
  • Souhaitable : Mise en place de jeux de tests fonctionnels avec des technologies de type selenium - Un seul test simpliste implémenté
  • Souhaitable : utilisation webservice - Utilisation de cpville[3]
  • Optionnel : abonnement rss - Un flux d'historique des accès.
  • Optionnel : partie du site en gwt ou au moins avec un framework type smartclient - Partie non réalisée
  • Supplémentaire : Ajout d'un envoi de mail en cas de remise à zéro d'un mot de passe utilisateur. (serveur SMTP non actif)

Spécifications

Principe de fonctionnement

La base de données de l'application contient différentes informations sur les utilisateurs et les cartes qui leur sont associées. Elle contient aussi l’arborescence des zones et les capteurs qui permettent d'ouvrir les accès d'une zone à une autre. Chaque zone comporte une liste d'utilisateurs qui sont autorisés à pénétrer à l'intérieur de celle-ci. Quand un utilisateur présente une carte devant un capteur, l'application vérifie qu'il est autorisé à pénétrer dans la zone. Ici cette action peut être simulée via une page de test qui est accessible sans connexion à l'application. Chaque test donne lieu à la sauvegarde d'un évènement. Ces évènements sont distribués via un flux RSS.

Rôles

  • Utilisateur non connecté :
    • Il peut tester un accès grâce à un numéro de capteur et un numéro de carte.
    • Il peut se connecter.
  • Utilisateur connecté:
    • Il peut se déconnecter.
    • Il peut accéder à toutes les fiches utilisateur via un champs de recherche.
    • Il peut visualiser ses cartes (leur validité, date de création, date d'expiration).
    • Il peut accéder aux fiches des zones (présentant les responsable de la zone ainsi que la liste des utilisateurs autorisés à y accéder)
    • Il peut modifier son mot de passe.
    • Il peut s'abonner au flux RSS.
  • Responsable de zone:
    • Il peut ajouter et supprimer des autorisations d'accès à la ou aux zone(s) dont il est responsable.
  • Administrateur:
    • Il peut ajouter et modifier des utilisateurs.
    • Il peut ajouter des cartes à un utilisateur ou en invalider.
    • Il peut réinitialiser un mot de passe utilisateur.
    • Il peut ajouter et modifier les zones.
    • Il peut ajouter des capteurs correspondant à un accès entre deux zones.
    • Il peut ajouter et supprimer des responsables de zones.

Cas d'utilisation

Perrettc usecase.png

Diagramme entité relation

Le diagramme ci-dessous correspond à la base de données de l'application. L'implémentation est différente car initialement nous avions prévu de gérer plus de choses. Perrettc diagclass.png

Environnement Technique

  • Serveur Web
    • Apache Mina - (Play Framework)
  • BDD
    • H2 Database en DEV
  • Workflow
    • Git pour le versionning
    • Github (issues + pull requests)

Avancement du projet

Avancement général :
100 %

Conception

Rédaction des cas d'utilisation :
100 %
Modélisation des cas d'utilisation :
100 %
Modélisation du schéma de données :
100 %
Conception du design de la page d'accueil :
100 %
Conception du design de la page utilisateurs :
100 %
Conception du design de la page zones :
100 %
Conception du design de la page test :
100 %
Conception du design de la page de connexion :
100 %

Développement

Réalisation des classes du modèle :
100 %
Réalisation des vues :
100 %
Réalisation des contrôleurs :
100 %
Ajout du flux RSS :
100 %
Ajout du web service :
100 %

Tests

Réalisation des tests unitaires :
100 %
Réalisation d'un test applicatif :
100 %
Réalisation d'un test sélénium :
100 %


Autre

Mise en place d'un environnement de travail (git+github) :
100 %
Réalisation d'un jeu de données :
100 %
Réalisation de la page ensiwiki :
100 %
Réalisation d'un screen cast :
100 %

Installation et déploiement

Lors d'un déploiement de notre application web, vous devez créer une zone "Racine" et un utilisateur administrateur, sinon elle ne sera pas fonctionnelle.

utilisation au quotidien

Nous nous sommes rendu compte que pour une utilisation en situation réelle, la connexion réseau entre un capteur et le serveur devait être protégée en authentification et confidentialité. Comme M. Viardot l'a suggéré, le plus simple serait d'utiliser deux couples de clefs RSA. Les communications pourraient ainsi être chiffrées entre les différents outils, de plus le capteur pourrait authentifier la réponse du serveur pour le déverrouillage d'une porte.

Screencast

Media:perrette_screencast.mp4

Retour d'expériences

Ce projet a été pour nous l'occasion de découvrir le framework Play et même pour l'un d'entre nous de découvrir un framework web et ce fut une très bonne expérience.

Nous sommes tout de même déçus de ne pas avoir réalisé toutes les fonctionnalités que nous avions imaginées, comme la gestion des demandes d’accréditation d'un utilisateur à un responsable de zone, mais nous avions vu peut-être trop grand pour une première application. Nous avions aussi pensé à mettre en place un site en HTTPS mais nous avons finalement renoncé, la aussi par manque de temps.

En ce qui concerne l'utilisation du framework, il reste assez simple à utiliser et très bien documenté, nous avions choisi de gérer les profils des utilisateurs nous même car nous pensions que cela serait plus simple dans un premier temps, mais nous pensons que les outils du framework (CRUD) auraient été plus pratiques.