Discussion :

[cashmoney]

Bonjour,

J'ai codé une méthode qui me permet de déconnecter mon utilisateur en vérifiant si la session créée par le navigateur existe toujours, si la session est détruite, déconnecter mon utilisateur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
package ci.session;
 
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;
import org.apache.log4j.Logger;
import org.springframework.stereotype.Service;
import ci.bean.User;
import ci.service.*;
 
@Service
public class UserSessionListener implements HttpSessionListener {
 
    private Logger log = Logger.getLogger(UserSessionListener.class);
 
    private MessageServices messageService;
 
    public void sessionCreated(HttpSessionEvent se) {
 
        // log request of the INFO level
        log.info("Session créée: " +se.getSession().getId());
    }
 
    public void sessionDestroyed(HttpSessionEvent se) {
 
        //messageService = new MessageServiceImpl();
 
        HttpSession session = se.getSession();
 
        /*// Liaison avec le WebApplicationContext
        ApplicationContext ctx = WebApplicationContextUtils
                .getWebApplicationContext(session.getServletContext());
                BeanFactory factory = ctx;
                */
 
        // Suppresion de l'utilisateur dans la liste des connectés
        try{
        User user = (User) session.getAttribute("user");
        messageService.removeUser(user);
        }
        catch(Exception ex){
            log.error(ex.getMessage(), ex);
        }
        // log request about session's that are invalidated
        log.info("Session détruite: " + session.getId());
    }
}

A l'ouverture du navigateur, ma session se crée mais ne se détruit pas à la fermerture.

Quelqu'un saurait-il m'indiquer comment faire ?

Merci d'avance pour votre aide.

[fr1man]

C'est normal, quand tu fermes ton navigateur, ton application serveur n'est pas avertie de l'événement.
Essaie avec un petit javascript qui détectera la fermeture de la fenêtre et qui appellera une servlet s'occupera de la destruction de la session.

[Alain Defrance]

Bonjour,

C'est normal, quand tu fermes ton navigateur, ton application serveur n'est pas avertie de l'événement.

Non c'est faux,

Essaie avec un petit javascript qui détectera la fermeture de la fenêtre et qui appellera une servlet s'occupera de la destruction de la session.

Quelle horreur.

Concernant le problème proprement dit, lorsqu'on fait appel à HttpServletRequest.getSession(), une session est automatiquement créée. Pour détruire une session il faut appeler HttpSession.invalidate(). Seulement attention lorsque l'on fera à nouveau appel à getSession, elle sera recréée. Pour récupérer la session uniquement si elle existe, il faut appeler HttpServletRequest.getSession(false), dans ce cas, on aura null si la session n'existe pas.

PS : Ici tu a l'air de faire de la "sécurité", je t'invite donc à regarder du côté de JAAS qui est fait pour.

On ne code pas en Java comme en PHP !

[tchize_]

C'est normal, quand tu fermes ton navigateur, ton application serveur n'est pas avertie de l'événement.

Non c'est faux,

Si c'est vrai Le protocole http ne prévois rien pour qu'un navigateur informe le serveur de la destruction des cookies. Le plus simple c'est de gentillement attendre le timeout de la session. Rien à faire, peinard.

Et je confirme, la solution javascript, évite! C'est pas fiable et ça n'apporte rien.

[Alain Defrance]

Si c'est vrai Le protocole http ne prévois rien pour qu'un navigateur informe le serveur de la destruction des cookies.

Ce que je voulais dire par là, c'est que c'est pas normal et que l'on a pas à gérer cela. On va tout simplement perdre la session même si elle sera toujours active sur le serveur, puis elle sera détruite lorsqu'elle atteindra la fin de sa vie (défini dans web.xml).

En effet je confirme que le protocol HTTP ne permet pas d'informer le serveur que la session n'est plus connue par le client.

[fr1man]

Ce que je voulais dire par là, c'est que c'est pas normal et que l'on a pas à gérer cela. On va tout simplement perdre la session même si elle sera toujours active sur le serveur, puis elle sera détruite lorsqu'elle atteindra la fin de sa vie (défini dans web.xml).

Faut un peu arrêter de raconter n'importe quoi.
Selon le type d'application, on peut avoir envie de détruire sa session présente sur le serveur, notamment si on a beaucoup de données stockées et que le timeout est très long. Pour ceci, on peut soit attendre qu'elle se détruise d'elle même grâce au timeout, soit on peut la détruire en faisant un appel serveur.
On retrouve cette façon de faire pour les boutons de déconnexion sur les sites de banque en ligne par exemple.
L'idée du unload en javascript qui sera appelé notamment lors de la fermeture du navigateur, et même si ce n'est pas parfait, c'est toujours mieux que rien.

EDIT: Le unload n'est pas forcément terrible ok, mais un bouton ou un lien pour détruire la session, je trouve ça très propre, même si on a pas de garantie qu'il sera utilisé.

[Alain Defrance]

Faut un peu arrêter de raconter n'importe quoi.
Selon le type d'application, on peut avoir envie de détruire sa session présente sur le serveur, notamment si on a beaucoup de données stockées et que le timeout est très long. Pour ceci, on peut soit attendre qu'elle se détruise d'elle même grâce au timeout, soit on peut la détruire en faisant un appel serveur.
On retrouve cette façon de faire pour les boutons de déconnexion sur les sites de banque en ligne par exemple.
L'idée du unload en javascript qui sera appelé notamment lors de la fermeture du navigateur, et même si ce n'est pas parfait, c'est toujours mieux que rien.

Trois posts plus haut je parle de la méthode invalidate. : http://java.sun.com/products/servlet...l#invalidate()

EDIT: [...] je trouve ça très propre [...]

[fr1man]

Tu le fais exprès ?
Jusqu'à preuve du contraire, cette méthode s'appelle du côté serveur, il faut donc que le client l'appelle, c'est pour cela que je propose un lien, un bouton...

[Alain Defrance]

Un bouton qui mène vers une action qui appèle un invalidate et forward sur une page (celle d'acceuil du visiteur par exemple) ...
Je suis pas certain qu'on arrive à bien se comprendre

[fr1man]

Oui et alors, c'est exactement ce que je propose.
Et je ne vois toujours pas le problème avec cette façon de faire.
Après que tu rediriges ou pas vers une page d'accueil, tu fais bien ce que tu veux...
On parlait au départ uniquement de destruction de session.

[Alain Defrance]

Oui et alors, c'est exactement ce que je propose.
Et je ne vois toujours pas le problème avec cette façon de faire.
Après que tu rediriges ou pas vers une page d'accueil, tu fais bien ce que tu veux...
On parlait au départ uniquement de destruction de session.

Ok dans ce cas on est d'accord on s'est juste mal compris, encore à cause de javascript ça

[fr1man]

Tout à fait.
L'idée du javascript, c'était pour récupérer l'événement de fermeture du navigateur et ainsi appelé le invalidate côté serveur.
Mais bon, on est d'accord qu'on peut bricoler avec l'événement unload, mais ce n'est pas parfait.

[Alain Defrance]

Mais bon, on est d'accord qu'on peut bricoler avec l'événement unload, mais ce n'est pas parfait.

On peut toujours bricoler ...
Comme tchize_, je suis d'avis de ne pas me préoccuper de ceci. La session se fermera bien quand elle se fermera... Pour peut que la personne qui a créer le dd ait bien fait son travail, la session ne sera pas persistante bien longtemps ...

[fr1man]

En soit, je suis assez d'accord avec toi, mais j'ai déjà bossé sur des applications, où le timeout de la session était très élevé, de l'ordre d'une journée, et les données présentes en session prenaient pas mal d'espace.
Je ne suis pas pour ce genre de choses, mais des fois, on a pas le choix, et donc on en finit par devoir gérer ce genre de problème.

[Alain Defrance]

En soit, je suis assez d'accord avec toi, mais j'ai déjà bossé sur des applications, où le timeout de la session était très élevé, de l'ordre d'une journée, et les données présentes en session prenaient pas mal d'espace.
Je ne suis pas pour ce genre de choses, mais des fois, on a pas le choix, et donc on en finit par devoir gérer ce genre de problème.

Ah mais il y a un écart énorme entre la théorie et la réalité du développeur. Dans l'absolu il faut éviter, mais dans la pratique on fait des trucs dégeulasses

[cashmoney]

Du calme les amis, on est là pour résoudre mon soucis. Merci pour vos réponses rapides.
En ce qui concerne un javaScript, je ne peux pas le faire, je suis conditionner de tout faire sous flex et java alors éclairer moi.
concernant la méthode sessionDestroy() j'ai lu dans la javadoc qu'il fallait l'utiliser afin de détruire la session en cours en cas de fermeture du navigateur.
Alors j'ai l'ai plaqué dans mon code aussi simple que ça.
Pour la méthode sessionInvalidate(), j'ai lu mais je n'ai pas compris tout à fait l'utilisation, si on peut me donner un lien bien expliquer, cela me ferait du bien

[Alain Defrance]

HttpSession.invalidate() détruit la session.
Quant à sessionDestroy() ça ne me dit rien oO

[cashmoney]

Ha bon, sessionDestroy() ne te dit rien, bizarre ça. Dans tous les cas, merci mais tu n'as pas un petit aperçu ou un lien?? merci

[tchize_]

au moment approprié (à toi de juger ce qu'est le moment approprié) dans ta servlet tu fais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

session.destroy();

Du coté client t'as plus qu'à effectuer la requete vers ton serveur qui déclenchera le bout de code concerné.

Quand à sessionDestroy(), cette méthode n'existe pas dans les spécification J2EE, donc j'ignore d'ou tu la sort.

[c_nvy]

Quand à sessionDestroy(), cette méthode n'existe pas dans les spécification J2EE, donc j'ignore d'ou tu la sort.

cashmoney fait référence à la méthode sessionDestroyed de HttpSessionListener (voir le code posté dans son premier message).