Problème Filtre controlant l'existance d'une session

Bonjour, je cherche à créer un filtre permettant de contrôler qu'un utilisateur est bien connecté lorsqu'il accède à une ressource du site.

Le filtre marche bien . Je test dans ce filtre si la session est null ou pas :

Code:

---

1 2 3 4 5 6 7

HttpSession session = request.getSession(false) if(session == null){ //redirection sur la page d'accueil. } else { // On continue la requête vers la ressource demandées }

---

Cela fonctionne bien si je me déconnecte et que je quitte puis relance Firefox.
Si je rentre une URL du site , je suis bien rediriger vers le formulaire de connexion.

Par contre si je me déconnecter et entre une URL du site sans quitter Firefox, je tombe en erreur car la session n'est pas null mais ne contient plus non plus les identifiants de l'utilisateur.

Il semblerai que Firefox retienne l'id de la session même après un :

Code:

---

1 2	session.invalidate(); session = null;

---

Comment-puis-je empêcher ça?

Après recherche , je crois que le

Code:

---

session.invalidate()

---

ne marche pas.
ou alors le

Code:

---

request.getSession(false)

---

sensée retourner null si la session est invalide ne joue pas son rôle.

Peux-tu essayer d'ajouter l'option must-revalidate dans le header ?

Exemple :

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0); // Proxies.

quand tu fais un session.invalidate(), la session est jetée, le cookie du navigateur n'est plus reconnu. Par contre, si dans la même requête, plus loin, tu fais un getSession(), tu va recréer une nouvelle session, vide, et la transmettre au navigateur. C'est, je pense, ce qui se passe dans ton cas, donc vérifie bien le code exécuté après ce invalidate. Aussi, vérifie ton firefox, son cookie JSessionID ne devrait pas être changé par le "déconnexion" que tu fais.


PS: il est préférable cependant de revoir ton test comme ceci pour être plus robuste:

Code:

---

1 2 3 4 5 6 7

HttpSession session = request.getSession(false) if(session == null ||session.getAttribute("UtilisateurEstLoggueEtValide")==null){ //redirection sur la page d'accueil. } else { // On continue la requête vers la ressource demandées }

---

L'id de session est très certainement calculé en fonction d'éléments du client et du serveur, il est normal que cet id ne change pas.
On a fait des tests, on a 3 instances de jboss sur un même serveur (physique) et toutes les applications ont le même id session.
Ce n'est pas plus gênant que ça, les zones de stockage des objets en session sont elles bien séparées.

Dans ton cas, je pense que tu dois avoir quelque part un request.getSession() qui traine... mais le session.invalidate() fonctionne à mon avis puisque tu n'as plus d'objets.

normalement l'id de session doit être aléatoire. Sinon, cela signifie que je peux le précalculer et me faire passer pour quelqu'un d'autre!
Es-tu sur que les trois instance n'ont pas été configurées pour faire partie d'un même cluster avec des système de single sign on?

Je viens de tester ici, un seul serveur jboss, un invalidate entre deux session, c'est bien deux JSESSIONID différents. Par contre, le invalidate ne détruit pas le cookie, c'est uniquement le request.getSession(true) suivant qui remplacera le cookie.


Au fait, pour rappel, les pages JSP, par défaut, créent une session si on n'a pas mis session=false dans le tag @page. Ca expliquerais pourquoi tu récupère une session après le invalidate si tu redirige l'utilisateur vers un tel jsp.

J'ai enfin résolus le probleme. Effectivement la JSP recrée un identifiant de session a chaque fois. Le test suggéré sur l'existence de l'attribut session ma partie de bien réussir le test.
Merci beaucoup.