Gestion de Session en J2EE
Section 1 - Inconvénients du protocole HTTP et utilité du suivi de session Le protocole HTTP est un protocole "sans état" (fonctionnant en mode déconnecté). Cela signifie que chaque requête envoyée par un client est traitée de manière totalement indépendante des autres.
D'après le document Gestion de Session en J2EE
Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source
Servlets, Cookies, HTTP Session Management · PDF · 10 pages
Afficher l'aperçu du document
Section 1 - Inconvénients du protocole HTTP et utilité du suivi de session
Le protocole HTTP est un protocole "sans état" (fonctionnant en mode déconnecté). Cela signifie que chaque requête envoyée par un client est traitée de manière totalement indépendante des autres. Nativement, le serveur est dans l'impossibilité de garder des informations d'une requête à une autre, et donc d'identifier qu'une série de requêtes provient d'un même client.
Pour pallier ce problème, on utilise le suivi de session (session tracking). Ce mécanisme a pour buts principaux :
- De reconnaître les requêtes provenant du même utilisateur.
- D'associer un profil spécifique à cet utilisateur.
- De conserver et connaître les paramètres de l'application liés à cet utilisateur.
Le document propose deux solutions principales pour le suivi de session : les Cookies et l'objet HttpSession.
Section 2 - Concept et utilisation des Cookies
Un Cookie est une information générée et envoyée par le serveur, qui est ensuite stockée localement sur le poste du client (par le navigateur). Le client renverra automatiquement cette information au serveur lors de ses prochaines visites sur la même URL.
Les Cookies sont particulièrement utiles pour :
- L'identification des utilisateurs.
- Éviter à l'utilisateur de devoir saisir des informations de manière répétitive (comme un login, un mot de passe, une adresse ou un numéro de téléphone).
- Gérer les préférences et les profils des utilisateurs.
Section 3 - Les Cookies : Sécurité et limites matérielles
Contrairement à certaines idées reçues, les Cookies présentent des garanties de sécurité inhérentes à leur conception :
- Aucun risque de virus : Un Cookie n'est jamais interprété ni exécuté par le système.
- Non partageable : Le navigateur garantit qu'un Cookie n'est redistribué qu'au serveur spécifique qui en est l'émetteur.
Afin de prévenir la surcharge du disque dur de l'utilisateur, des limites strictes sont imposées :
- La taille maximale d'un Cookie est de 4 KB (kilooctets).
- Les navigateurs limitent le stockage à un total de 300 Cookies maximum.
- Un même site ne peut stocker plus de 20 Cookies.
Section 4 - Gestion des Cookies en Java (API Servlet)
La manipulation des Cookies en Java se fait via la classe javax.servlet.http.Cookie.
- Création : On utilise le constructeur qui prend une paire clé/valeur en paramètres :
Cookie(String nom, String valeur). - Écriture (Envoi au client) : On utilise la méthode
public void addCookie(Cookie c)qui appartient à l'objetHttpServletResponse. - Lecture (Réception depuis le client) : On utilise la méthode
public Cookie[] getCookies()qui appartient à l'objetHttpServletRequest. Elle retourne un tableau contenant tous les cookies envoyés par le client.
Section 5 - Méthodes principales de la classe Cookie
La classe Cookie fournit plusieurs méthodes pour interagir avec les attributs du cookie :
public String getValue()/public void setValue(String valeur): Permettent de récupérer ou de modifier la valeur associée au cookie.public String getName()/public void setName(String valeur): Permettent de récupérer ou de définir le nom du cookie.public int getMaxAge()/public void setMaxAge(int duree): Permettent de récupérer ou de définir la durée de vie (validité) du cookie, exprimée en secondes.public String getPath()/public void setPath(String chemin): Permettent de récupérer ou de définir le chemin d'application pour lequel le cookie est valide.
(Note : La page 7 du document source intitulée "EXEMPLE" est vide. Aucune donnée n'y figurant, cet exemple ne peut pas être restitué.)
Section 6 - L'interface HttpSession
L'interface HttpSession permet de créer et de gérer une session côté serveur entre un client HTTP et un serveur HTTP.
Contrairement aux requêtes individuelles, cette session persiste dans le temps, couvrant plusieurs connexions ou plusieurs demandes de pages effectuées par le même utilisateur. Elle est généralement utilisée pour lier un identifiant de session unique (session id) à un ensemble de données stockées sur le serveur concernant cet utilisateur.
Pour obtenir l'objet HttpSession, on utilise la méthode suivante de la classe HttpServletRequest :
public HttpSession getSession(boolean creation)
Le paramètre booléen creation dicte le comportement de la méthode : elle rend la session liée à la requête courante ; si elle n'existe pas, elle renvoie null (si creation vaut faux) ou crée une nouvelle session (si creation vaut vrai).
Section 7 - Méthodes principales de l'interface HttpSession
Les méthodes clés pour manipuler les données d'une session sont :
public void setAttribute(String nom, Object valeur): Enregistre l'objetvaleurdans la session, et l'associe à la clénom.public Object getAttribute(String nom): Récupère l'objet stocké sous la clénom. Retournenullsi cet attribut n'existe pas.public void removeAttribute(String nom): Supprime l'attribut associé à la clénomde la session.public void invalidate(): Détruit la session entière et supprime les données associées.public void logout(): Permet de terminer la session.
Section 8 - Correction de l'exemple de code (Servlet)
Le code fourni à la fin du document source contient plusieurs erreurs de compilation causées par l'extraction et des fautes de frappe. Voici les corrections apportées pour que le code soit fonctionnel :
- Importations manquantes : L'utilisation de
IOExceptionetPrintWriternécessite l'importation du packagejava.io.*. - Erreur de typographie : Le cast
(Inrteger)a été corrigé en(Integer). - Guillemets invalides : Les guillemets français
«et»ont été remplacés par des guillemets standards"exigés par la syntaxe Java.
Voici le code corrigé :
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*; // Ajout indispensable pour IOException et PrintWriter
class MaServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
HttpSession session = req.getSession(true);
// Correction de la faute de frappe "Inrteger" et des guillemets
Integer cpt = (Integer) session.getAttribute("compteur");
if (cpt == null) {
cpt = new Integer(1);
} else {
cpt = new Integer(cpt.intValue() + 1);
}
// Correction des guillemets
session.setAttribute("compteur", cpt);
PrintWriter out = res.getWriter();
// Correction des guillemets pour la concaténation de la chaîne
out.println("Vous avez visité cette page " + cpt + " fois");
}
}
Méthode
Pour aborder ce type d'évaluation portant sur J2EE, il est essentiel de bien distinguer où se fait le stockage de l'information :
- Côté Client : Les Cookies. Vous devez mémoriser qu'on les lit depuis la requête (
HttpServletRequest) mais qu'on les crée et les envoie via la réponse (HttpServletResponse). Gardez en tête leurs limitations de taille (4KB) et de quantité. - Côté Serveur : L'objet
HttpSession. Les données volumineuses et sensibles y sont stockées en mémoire. Le pont entre le client et le serveur se fait via un identifiant de session transparent pour le développeur. - Analyse de code : Lors de la lecture d'extraits de code sur une copie, vérifiez systématiquement les "casts" (transtypages) d'objets récupérés via
getAttribute()(qui retourne un type génériqueObjectdevant être converti, comme(Integer)ici), et assurez-vous que les méthodes appelées appartiennent aux bonnes interfaces.
Commentaires
Aucun commentaire pour le moment. Posez la première question.