Présentation

TIX est une plateforme web en langage PHP et SQL (MariaDB) qui a pour objectif de recueillir les demandes de dépannage des différents utilisateurs (étudiants et professeurs dans les salles machines).
Dans le cadre de cette SAÉ qui a duré tout le semestre, nous avons dû rendre des devoirs concernant la gestion des risques, l'utilisation des données, le chiffrement du mot de passe et les statistiques du site.
Nous avons dû installer le serveur, créer le site et sa base de données.

C'est une SAÉ très importante pour notre année, car sa note est coefficient 40. À elle seule, elle peut mettre fin à notre deuxième année de BUT Informatique.

Nous avions comme objectif de rendre l'application la plus sécurisée et la plus accessible que possible.
Malgré nos efforts, nous avons encore des progrès à faire.

Je vous recommande de lire le sujet de notre SAÉ pour en savoir un peu plus sur ce qui était demandé.

Cette page a été rédigée par Matthieu FARANDJIS et Assia GOUABI.
Note : "Je" sur cette page réfère à Matthieu FARANDJIS.

Gestion du projet

Nous étions un groupe de 5 pour faire ce projet, j'ai été désigner chef de projet.
Mon rôle était de gérer le projet et de l'organiser au mieux.

J'attribuais les tâches à mes coéquipiers en fonction de leurs points forts. Je n'ai jamais travaillé avec Assia et Enzo, j'ai donc dû apprendre à les connaître.
Toute les semaines, je faisais un bilan de notre avancée. J'y expliquais ce qui était fait, et ce qui restait à faire.
Au début de la SAÉ, j'avais créé un planning, mais celui-ci demande du temps et la possibilité de se projeter. Vu qu'on était régulièrement confronté à des problèmes qui nous retardaient et que j'étais très sollicités, progressivement j'ai fusionné ce planning avec le bilan de la semaine.

Pour le dépôt GIT, nous avons décidé de suivre l'arborescence du site. Par exemple, la page inscription appartient au répertoire authentification, qui lui-même appartient au répertoire du site.
Il y avait donc une branche propre à la page, une branche propre au répertoire (auquel on allait fusionner avec les sous-branches) et la branche du site dynamique (qui fusionnera avec ses sous-branches également).
Toute la conception, le développement et les tests d'une page se faisaient sur la branche. Nous suivions donc le cycle en V.

Les utilisateurs, techniciens et administrateurs de TIX

L’application est composée de plusieurs type de personne présentant chacun un rôle différent au sein de la plateforme. Nous pouvons citer parmi eux les visiteurs, les utilisateurs, les techniciens, l’administrateur web et système.

Les utilisateurs permettent de garder l’application active en formulant des tickets de demande de dépannage. Les administrateurs consultent et gèrent des données internes à la plateforme et les techniciens sont chargés de résoudre les problèmes signalés par les utilisateurs.

Les visiteurs ont seulement la possibilité de consulter la page d’accueil regroupant des informations de présentation de l’application web telles qu’un texte présentatif du but de celle-ci ou la vidéo expliquant comment utiliser chaque page du site web. Le visiteur voit également les 10 derniers tickets formulés par les utilisateurs peu importe leur état et peut s’inscrire ou se connecter à la plateforme. Ainsi, si un visiteur tente par plusieurs moyens de s’introduire dans les différentes pages dédiées aux utilisateurs inscrits ou connectés, le système lui demandera de s’authentifier.

Les utilisateurs possèdent davantage de droits face aux visiteurs. Ils peuvent accéder à leur tableau de bord à partir de la page d’accueil ou la page de profil. Dans la page tableau de bord ils peuvent visualiser les différents tickets formulés par les autres utilisateurs mais également leur propre ticket. En ajoutant à cela qu'ils peuvent modifier un ticket qu’ils auraient rédigé à condition que ce ticket n’a pas été pris en charge par un technicien. Les utilisateurs créent des tickets où ils renseignent des problèmes de thématiques diverses et variées. Dans cette page, ils possèdent aussi la possibilité de rechercher des tickets ou un ticket en particulier avec des caractéristiques spécifiques telles que la date, le titre, les mots-clés ou le type de ticket, s’il s’agit de demandes actuelles ou tous les tickets présents. Ainsi, cette recherche leur permettra de faciliter l’identification de tickets et l’utilisation de l’application. Les utilisateurs consultent leurs informations personnelles ou en modifier dans la page de profil qui est accessible depuis la page tableau de bord ou la page d’accueil. Ils peuvent modifier leur mot de passe ou leur email. Pour éviter d’avoir à chercher leurs tickets formulés dans le tableau de bord pour voir s’ils ont bien été pris en charge, la consultation de leur demande peut se faire dans la page de profil également. Enfin, un utilisateur a la capacité de pouvoir se déconnecter ou se désinscrire de la plateforme.

Les techniciens possèdent la capacité de réaliser les mêmes actions que les utilisateurs, mais ils bénéficient également du privilège de pouvoir modifier les tickets qui leur sont assignés en tant que techniciens. De plus, ils ont la faculté de s'auto-affecter des tickets si aucun technicien n'est actuellement chargé de la tâche et de fermer un ticket si c’est bien lui le technicien affecté.

L'administrateur web peut accomplir les mêmes opérations que les utilisateurs, à l'exception de la possibilité de modifier son propre mot de passe et de se désinscrire de la plateforme. Par ailleurs, il bénéficie de fonctions supplémentaires, notamment la capacité à modifier tous les tickets, à déterminer de manière définitive le niveau d'urgence, et à attribuer un ticket à un technicien. En outre, il a le pouvoir de fermer un ticket jugé résolu. Pour couronner le tout, l'administrateur web accède à la page d'administration, où il peut ajouter des techniciens à la liste existante, ainsi que gérer les titres et les mots-clés en ajoutant ou supprimant ces éléments selon les besoins.

L'administrateur système partage les fonctionnalités communes avec les utilisateurs, à l'exception de la modification de son propre mot de passe et de la désinscription de la plateforme. Cependant, il dispose du privilège d'accéder à la page d'administration, où il peut consulter diverses informations telles que les tickets fermés, les tentatives de connexion infructueuses, ainsi que les nouvelles ouvertures de tickets.

Accessibilité

Les extensions Chrome : Wave et axeDevTools en action sur la page d'accueil

L’accessibilité caractérise le fait que le site peut être utilisé par n’importe quel type de personne possédant ou non un handicap aussi varier soit-il. Que ce soit si la personne est aveugle, sourde, épileptique ou encore ne peut pas manipuler un clavier.

En plus de nos vérifications à l’aide des extensions Wave et axeDevTools qui reportent des erreurs dans le code HTML pouvant restreindre l’accessibilité et qui donne des conseils, nous sommes allés plus loin. Nous avons testé notre site avec le narrateur intégré de Windows. Malgré le fait qu’on puisse manipuler le site entièrement au clavier, le narrateur n’arrive pas à interagir avec certains éléments JavaScript comme les pop-ups. Ce qui est un défaut important de notre application. Cela signifie qu’une personne malvoyante ne pourrait pas modifier ou récupérer des informations supplémentaires sur ses tickets. Le narrateur n’est pas capable de lire les sous-titres HTML, et bien qu’il existe une fonctionnalité HTML d’audiodescription avec la balise track, aucun navigateur ne la supporte. De ce fait, nous devrons faire une transcription du contenu visuelle de la vidéo pouvant être lu par le narrateur de Microsoft. Nous devons également tester d’autres narrateurs, notamment sur mobile.

Nous avons également tenté d’utiliser le logiciel Photosensitive Epilepsy Analysis Tool (PEAT) qui permet de tester l’accessibilité des vidéos aux personnes souffrant d’épilepsie. Celui-ci peut lire une page web sur le navigateur Firefox ou lire une vidéo au format .avi. Il analyse celle-ci et affiche un graphique en temps réel de la sensibilité de l’œil à la vidéo.
Malheureusement, le logiciel ne semble plus être compatible avec Windows 10. Il lui manque des fichiers pour l’installation. Sa dernière version date de 2016. Toutefois, nous prévoyons de chercher des alternatives tout aussi efficaces que PEAT. L’épilepsie est une maladie pouvant être mortelle, TIX doit aider les utilisateurs lors de leurs demandes de dépannage, pas les handicapés.

Nous n’avons pas essayé de contrôler TIX à l’oral, ni de chercher à le faire. Nous devrons donc faire des recherches.

En plus de nos cours, nous nous sommes aidés du site sur l'accessibilité du gouvernement français ainsi qu'une page de conseil d'Orange.

Plus d'information sur...
PEAT : https://trace.umd.edu/peat/
Site du gouvernement sur l'accessibilité : https://accessibilite.numerique.gouv.fr/
Mémo d'Orange sur l'accessibilité : https://a11y-guidelines.orange.com/fr/res/memos/tests-web/Memo-Tests-Web-Orange.pdf

Sécurité

Capture d'écran de PHPMyAdmin montrant une vue qui n'a qu'accès aux informations personnelles d'Alice, l'utilisateur actuellement connecté à la base de données.

La sécurité est l’un de nos piliers centraux de notre SAÉ tout comme l’accessibilité. Nous voulions fournir un véritable travail dessus.

De primes abords, chaque usager de TIX possède son propre profil MariaDB avec un rôle MariaDB associé. Ainsi, l’administrateur, même s’il a les droits du rôle Utilisateur, il possède des droits supplémentaires dus à son rôle d’administrateur web.
L’utilisateur n’a accès uniquement à ses données personnelles du côté de la base de données. Il n’est donc pas possible, même en cas d’accès direct à la base de données, de voir ou de manipuler les données des autres membres. Tout ce que le site lui permet de faire et de ne pas faire, la base de données fait de même. L’administrateur web ne peut donc pas non plus supprimer le compte en passant par la base de données.

Il y a des déclencheurs qui non seulement automatisent des actions comme le changement d’un état d’un ticket, mais qui empêche la modification de certaines données. Comme les tickets fermés, même l’administrateur de la base de données ne peut pas les modifier.

Nous avons veillé qu’il n’était pas possible de contourner les protections HTML pour insérer des données incohérentes. Tel que mettre “Non compléter !” comme niveau d’urgence, de faire de l’injection de code HTML CSS JavaScript ou encore SQL dans les formulaires. Il n’est pas non plus possible d’accéder aux pages dont on n'a pas le droit d’accès. Comme les pages administrations si nous sommes utilisateurs, ou encore accéder à la page modification de Ticket pour modifier un ticket d’un autre utilisateur. Si l’utilisateur accède à une page qui n’existe pas, le message d’erreur 404 lui est affiché et il ne peut pas voir l’indexation des fichiers.

Enfin, pour éviter le piratage de compte par copie du cookie, nous avons installé un système de jeton. Un jeton est caractérisé par l’IP de connexion, l’horodatage et un nombre aléatoire. Lorsque l’utilisateur se connecte, ce nouveau jeton est associé à sa session. A chaque changement de page, l'horodatage est mis à jour pour réinitialiser le compte à rebours de 30min avant la déconnexion. S’il se déconnecte, le jeton est supprimé. Ce qui rend le cookie obsolète et donc plus du tout utilisable par quiconque.
Le stockage de l’IP permet d’éviter l’utilisation du cookie sur un autre ordinateur. Vu que c’est un système local, l’IP est propre à chaque machine.
Ainsi, l’utilisateur peut être sûr qu’il n’y aucun moyen qu’un pirate utilise le cookie pour accéder à son compte.
Le cookie session PHP est différent des cookies habituels. En effet, les informations du cookie sont stockées côté serveur et non pas côté utilisateur. Seul un identifiant d’accès permet de lier le navigateur au fichier. Dans tous les cas, le système lutte tout en permettant des connexions simultanées à un compte, si on passe bien par la page de connexion.
Côté serveur, les fichiers session sont supprimés à chaque redémarrage du serveur si nous n’avons pas donné de durée de vie au fichier.

Ajouts et améliorations à faire

Nous souhaitons approfondir et améliorer certains aspects au cours du 4ème semestre. En ce qui concerne l'accessibilité, le narrateur Windows ne prend actuellement pas en compte certains éléments de notre site, tels que les pop-ups. Il est nécessaire de résoudre ce problème afin que les personnes malvoyantes puissent avoir une expérience complète de la plateforme. De plus, l'intégration d'une audiodescription à la vidéo de présentation faciliterait la compréhension pour ce public.

Actuellement, sur le site web, il est possible de sélectionner l'ensemble de la liste des mots-clés. Nous devrons ajouter quelques modifications pour limiter cette sélection. En ce qui concerne les ajouts, nous envisageons la possibilité de bannir un utilisateur de l'application en cas de comportement non conforme aux valeurs de l'application ou en cas de non-respect des règles. De plus, la possibilité de supprimer un ticket serait également à considérer.

Enfin, nous avons envisagé quelques fonctionnalités à ajouter, telles qu'un chat de discussion entre les utilisateurs et la possibilité pour les utilisateurs de télécharger une photo de profil.

Lancer le projet

Le projet a été créé à l'aide de l'IDE PHP PHPStorm (Jetbrains).

Pour tester ce projet, vous pouvez installer un serveur local de test sur votre ordinateur Windows à l'aide du logiciel XAMPP.
Cependant, je ne décrirais pas son installation.
Sinon, vous pouvez installer un serveur Linux Apache MariaDB PHP. Le rapport d'installation est disponible sur le dépôt

Importez le site, puis installez sa base de données via un compte MariaDB administrateur. Suivez l'ordre des fichiers dans le répertoire d'installation.