D03-TP05- Jakarta EE : La portée des objets

Nous poursuivons le développement de l'application de gestion des clients Actuellement, lorsqu'un utilisateur valide la création d'un client, un message s'affiche afin de confirmer la création dans la base de données.

1. Comment l’identifiant créé au niveau de la couche modèle peut-il être affiché au niveau de la vue (page JSP) ?
2. Avons-nous actuellement les moyens d'afficher les identifiants de tous les clients venant d'être créés ?

La portée des objets (visibilité ou scope) définit leur durée de vie.

Il existe 4 portées différentes :

• page (pour les JSP uniquement) : les objets de cette portée ne sont accessibles qu'au niveau de la page JSP.
• requête : les objets de cette portée sont uniquement accessibles durant l'existence de la requête, dès que la réponse est re-transmise, elle disparaît.
• session : les objets de cette portée restent accessibles durant l'intégralité de la connexion d'un utilisateur.
• application : les objets de cette portée sont accessibles durant l'existence de l'application pour tous ceux qui se connectent.

Il est possible de créer et de manipuler des objets de portées requête, session ou application depuis une page JSP ou depuis une servlet.

1. Quel type d'objet devrions-nous mémoriser afin de pouvoir afficher la liste des clients venant d'être créés ?
2. Quelle sera la portée la plus pertinente pour cet objet ?

La session représente un espace mémoire alloué pour chaque utilisateur, permettant de sauvegarder des informations tout au long de leur visite.

Le contenu d'une session est conservé jusqu'à la fin de la connexion de l'utilisateur, ou après un délai d'inactivité trop long.

L'objet Java qui gère une session est HttpSession.

La méthode getSession de l'objet HttpServletRequest permet de récupérer la session si elle existe, ou d'en créer une :

HttpSession maSession = request.getSession(); 

La méthode getAttribute(“nomAttribut”) appliquée à la session permet de récupérer un attribut sauvegardé.

Exemple :

String maChaine = null; 
if (maSession.getAttribute("monAttribut" != null) { 
String maChaine = (String) maSession.getAttribute("monAttribut"); } 

La méthode setAttribute appliquée à la session permet de sauvegarder les attributs.

Exemple :

maSession.setAttribute("monAttribut", maChaine);

La chaine de caractères maChaine sera sauvegardée dans un attribut de session sous le nom de monAttribut.

maSession.removeAttribute("monAttribut"); 

${sessionScope.nomVariable} 

Au niveau de la méthode doPost de la servlet NouveauServlet, avant la redirection vers la couche vue, il faut :

1. Récupérer la session
2. Rechercher la collection des nouveaux clients si elle existe, si elle n'existe pas il faut la créer.
3. Ajouter le nouveau client créé à cette collection.
4. Sauvegarder la collection des nouveaux Clients au niveau de la session

(Code à ajouter avant la redirection vers la jsp)

if (idClient != -1) { 
 // Ajout du no du client créé, dans une collection d’entiers stockée en session 
 // 1, Récupération de la session 
HttpSession maSession = request.getSession(); 
 // 2. Récupération de la collection des clients si elle existe, création sinon 
 ArrayList<Integer> lesNouveauxClients = (ArrayList<Integer>)  maSession.getAttribute("lesNvxClients"); 
 if (lesNouveauxClients == null) { 
 lesNouveauxClients = new ArrayList<>(); 
 } 
 // 3. Ajout du no du client créé dans la collection 
 lesNouveauxClients.add(idClient); 
 // 4. Mise à jour de la session 
 maSession.setAttribute("lesNvxClients", lesNouveauxClients); } 

Il faut désormais afficher le contenu de la collection lesNvxClients. En java, il faudrait ;

• Récupérer la session
• Récupérer la collection lesNvxSalaries
• Faire une boucle de parcours de la collection et afficher chaque no de client

Avec JSTL, on pourra écrire :

 
<article> 
 <h3>Liste des numéros des clients récemment créés : </h3>  <c:forEach items="${sessionScope.lesNvxClients}" var="unClient">  ${unClient} - 
 </c:forEach> 
</article> 

L'identifiant de l'objet de type HttpSession créé est placé dans la réponse retournée au navigateur du poste client et celui-ci l'enregistre.

1 1 Les schémas sont extraitsde “Créer des applications web avec JavaEE”, Site du Zéro

• Se positionner sur l'onglet Réseau des outils de développement, recharger la page et créer un nouveau client
• Cliquer sur la ligne de la requête POST, l'onglet Cookie permet de connaître son identifiant : valeur de JSESSIONID (Doc - Name = NouveauClient - Headers
• On retrouve également cet identifiant dans l'entête de la requête.

Actuellement, la page d'authentification existe, mais il est possible de passer outre : on peut aller directement à la liste des clients ou créer un nouveau client. (Ex :localhost:8080/Test2Jakarta/NouveauClient).

L'authentification concerne les salariés de l'entreprise il faut donc les gérer :

1. créer une table salarie dans la base de données qui contient leur login, mot de passe et leur rôle (estAdmin, booléen : administrateur ou pas)
2. créer la javabean SalarieMysql pour gérer les salariés (2 méthodes : readAll() et lireSalarie¹⁾)
3. créer une méthode existeUser(HttpServletRequest request) dans la classe AuthentifForm qui retourne un booléen pour vérifier l'existence de l'utilisateur dans la base de données
4. changer la méthode controlerAdmin de la classe AuthentifForm pour utiliser le rôle du salarié qui s'authentifie

Après une authentification réussie, il faudra mettre en session un booléen (isAuthentified) indiquant cette réussite ou non (méthode doPost de la servlet AuthentifServ.java, avant la redirection). De même, il faudra supprimer cette variable de session au niveau de la méthode doGet.

Ensuite il faudrait faire en sorte qu'aucune page ne puisse s'afficher sans passer par une authentification réussie.

Cette façon de procéder fonctionne, mais le problème, c'est qu'il faudrait reproduire cette modification dans toutes les servlets. Ce qui n'est pas satisfaisant. Au lieu d'apporter cette modification dans toutes les servlets, nous allons créer un filtre. Un filtre est un objet Java qui peut modifier les entêtes et le contenu d'une requête http avant l'intervention d'une servlet. Pour créer un filtre : * onglet File>New File>Web>Filter puis Next. * Nommer ce filtre AuthentifFilter, indiquer le Package com.mycompany.filter, puis Next * Cocher la case “Add information to deployment descriptor (web.xml)”, puis Next et Finish Dans la classe AuthentifFilter.java, remplacer le corps de la méthode doFilter par celui-ci : <code> Cast de l'objet request HttpServletRequest requete = (HttpServletRequest) request; Pas de filtrage des css, des images, des js String chemin = requete.getRequestURI().substring(requete.getContextPath().length()); if (chemin.startsWith(“/css”) || chemin.startsWith(“/images”) || chemin.startsWith(“/js”)) { chain.doFilter(request, response); return; } Récupération de la session HttpSession maSession = requete.getSession(); Récupération du booléen d'authentification boolean authentificationOK = false; if (maSession.getAttribute(“isAuthentified”) != null) { authentificationOK = (boolean) maSession.getAttribute(“isAuthentified”); } if (authentificationOK) { Poursuite sans problème chain.doFilter(request, response); } else { retour vers la page d'authentification request.getRequestDispatcher(“Accueil”).forward(request, response); } </code> Penser à adapter le nom du booléen d'authentification. Tester. Vérifier la présence de 2 nouvelles sections au niveau du fichier web.xml : <filter> et <filter mapping> <del>Peut-être avez-vous remarqué un problème concernant les caractères spéciaux (accent, tréma, …) saisis dans les formulaires. Pour remédier à ce problème, il faut ajouter un filtre qui permettra de spécifier le format d'encodage UTF-8 pour les données échangées. Télécharger filtreEncodage.xml depuis le Drive, et en copier le contenu dans votre fichier web.xml, redémarrer le serveur Tomcat (Services/Serveur/Restart) et tester. </del>

HttpSession maSession = request.getSession(); 

Type monAttribut = (Type) maSession.getAttribute("nomAttribut"); 

maSession.setAttribute("nomAttribut", attribut); 

À partir de la liste des clients, proposer la modification :

• Quand l'utilisateur souhaite modifier un client, il clique le lien hypertexte Modifier. Les données du client apparaissent au niveau du formulaire. La validation permet la mise à jour dans la base de données.

À vous de voir s'il y a besoin de créer des variables de session. Les méthodes doGet et doPost de la servlet se compliquent un peu : elles doivent désormais gérer les 2 cas : création ou modification.

Ajouter une colonne intitulée Action au tableau. Au niveau de chaque ligne de cette colonne, proposer “Modifier” qui sera un lien hypertexte vers nouveau?id=xx

1. Quelle servlet s'activera après un clic sur Modifier ?
2. Quelle méthode de cette servlet sera sollicitée ?

1. Changer la légende affichée au niveau de la partie formulaire
2. Afficher les données du client à modifier dans les 3 zones de texte du formulaire c. Mettre en évidence la ligne actuellement modifiée au niveau du tableau

1. Quelle servlet s'activera sur un clic du bouton Valider ?
2. Quelle méthode de cette servlet sera sollicitée ?

1. suppression d'un client
2. hachage du mot de passe
3. sécurisation de l'application
4. ajout favicon
5. …