Nous mettrons à jour notre Politique de confidentialité prochainement. En voici un aperçu.

Découvrir Java pour le web

Sécuriser l'accès au site

Testez gratuitement nos 1336 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Ajoutez un contrôle d'accès fiable par rôle qui s'appuie sur la base de données de l'application. Ce contrôle intègre également une page d'authentification et d'erreur.
08:04

Transcription

Notre application est quasiment terminée. Il ne nous reste plus qu'à implémenter une fonctionnalité importante : la fonctionnalité de sécurité. En effet nos utilisateurs ne sont pas réellement authentifiés. Ils ne rentrent à aucun moment un identifiant ou un mot de passe et ont accès à tout. Pour implémenter cette fonctionnalité il faut d'abord se rendre dans les fichiers de configuration. On va définir dans le fichier « web.xml » les rôles présents sur notre application. Ici, deux rôles, qui sont : le rôle d'administrateur du site, avec l'identifiant admin, et le rôle d'employé, avec « employe », sans accent bien-sûr, c'est un identifiant. Nous avons ensuite la forme d'authentification. Ici ça sera une authentification par formulaire. Ainsi les utilisateurs pourront rentrer leur login et leur mot de passe sur cette page « profil » que l'on va développer. Et s’il y a un problème, ils seront redirigés vers cette page. La page login est celle choisie par Tomcat pour rediriger les utilisateurs non authentifiés qui essaient d'accéder à une zone à laquelle ils n'ont pas le droit. Enfin, on doit définir des « security-constraint ». C'est-à-dire des contraintes sur la navigation du site. Ici on veut interdire l'accès à « suivi ». Donc on créé une ressource « Suivi d'activité » et on la restraint aux utilisateurs de rôle admin ou employé. Maintenant il va falloir associer ces rôles à des utilisateurs réels. Donc il va falloir définir ce qu'on appelle un royaume. Ce royaume est un moyen de trouver des utilisateurs et de les vérifier. Pour ça on va utiliser un royaume existant : « JDBCRealm », qui est géré par Tomcat. Il suffit de lui donner le driver JDBC qui lui permettra de retrouver et d'accéder à la base de données qui contient les utilisateurs. Attention : ce driver doit être installé sur le serveur et le conteneur Java. Donc Tomcat doit avoir dans son répertoire « lib » le « .jar » du driver JDBC. C'est très important. Il ne suffit pas de le mettre dans les paquets de l'application. Ensuite on spécifie le nom et le mot de passe de l'utilisateur qui va accéder à la base de données, et la chaîne de connexion à notre base de données. Ici c'est le mode d'encryptage du mot de passe. On a pris SHA1 qui est très bien géré par MySQL avec la fonction « SHA1() ». Et ici la table qui va stocker les utilisateurs. La colonne qui va stocker le nom d'utilisateur, la colonne qui va stocker le mot de passe. Les rôles admin ou employé seront stockés en face de l'utilisateur, dans la table « utilisateurs ». On aurait pu choisir une autre table dans la colonne « groupe ». Le dernier paramètre est important. Il permet de préciser que cette date est locale à l'application. Dernière étape : créer notre contrôleur et notre vue pour avoir un formulaire d'authentification. Pour ça, on va rajouter un contrôleur, une servlet. Par exemple : « ProfilServlet ». C'est les liens qu'on a mis dans le fichier de configuration « profil ». Cette servlet, comme notre autre contrôleur « suivi » va, dans un premier temps, gérer les paramètres qu'elle a reçus. Si elle est appelée avec un paramètre « p », on a vu dans le fichier de configuration que « profil » peut être appelé avec « p » pour spécifier une erreur, on va aussi l'utiliser pour se déconnecter. Donc « p » peut être appelé avec soit « erreur » soit « exit». Donc s’il est appelé avec « erreur », on va dire que le login et le mot de passe étaient incorrects et on va afficher un message d'alerte. Sinon, on va dire que ça s'est bien passé pour déconnecter la personne auquel cas il faudra invalider la session, c'est la méthode pour déconnecter un utilisateur qui a été authentifié par JDBC réellement. Nous allons aussi traiter un paramètre qui est le « qui » puisqu’on est sûrement redirigé quand on clique et qu'on n'a pas le droit d'accès et qu'on n'est pas authentifié. On va être redirigé vers cette page, donc on aura le paramètre qu'on utilisait pour savoir quel utilisateur était choisi. Là on va l'utiliser pour commencer à remplir le formulaire. On va le récupérer ici. Si jamais il y a un problème d'authentification on va permettre à la personne de ne pas avoir à retaper le nom d'utilisateur qu'elle a tapé pour qu'elle puisse réessayer son mot de passe. Maintenant que nous avons traité tous les paramètres, on peut les passer à notre vue. Comme on l'a fait jusqu’à maintenant, le « message », le « type » et « qui ». Et on va le passer à une vue qui s'appelle « profil.jsp ». On va faire un « profil.jsp » tout de suite. Nouveau JSP, « profil », une page entière. On a une page qui, en réutilisant notre template, est relativement brève à écrire. Il y a une partie pour définir un menu et la partie essentielle : le corps qui va définir un message d'erreur s’il y a un message affichage utilisateur d'un certain type. Soit « danger » pour alerter l'utilisateur d'un problème sur le login mot de passe. Soit de validation de sa déconnexion. Et puis, très important : le formulaire qui doit poster l'action « j_security_check » puisque c'est Tomcat qui va traiter ce formulaire et rediriger vers la page initialement demandée. Les noms de champs sont aussi imposés par Tomcat. Enfin, on utilise l'autofocus pour faciliter la saisie pour l'utilisateur, selon ce qui est déjà rempli. Maintenant on peut tester notre formulaire, notre contrôleur et notre vue. Lorsque l'on arrive ici, on va choisir un utilisateur. On va demander « suivi », mais « suivi » n'est pas accessible puisqu'on n'est pas authentifié. Donc on va s'authentifier, ici avec un mauvais mot de passe. Message d'erreur. On réutilise l'identifiant. Puis, le bon mot de passe. Et là j'arrive en rentrer sur mon espace. Si on veut se déconnecter il faudra faire le lien dans le menu. Pour l'instant on ne l'a pas fait. Pour l'instant il faut taper « profil?p=exit ». Mais c'est le lien que l'on mettra ensuite. Là on a bien été déconnecté. Donc on a vraiment quelque chose qui est sécurisé. Un mot de passe en « SHA1 » dans la base de données. Et impossible d'accéder à la page demandée si on n'est pas authentifié.

Découvrir Java pour le web

Développez une application web avec Java. Apprenez à écrire des servlets, des entités ​J​PA (Java Persistence API) d'accès aux données et des pages JSP (Java Server Pages).

2h06 (23 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :25 janv. 2017

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !