detection de fin de session

Version imprimable

09/02/2009, 09h40
SpaceFrog

detection de fin de session

Bonjour !

Alors voici ma problématique du jour...

J'ai une table de connectés ...
un champs bool updtadé determine si le user est connecté ou non.
Tout va très bien si le user se déconnecte normalement, ça me permet de faire un update de la table lorsque le user clique sur "deconnection" ...
mais quid si la deconnection est sauvage ?
A la limite sur le onbeforeunload de la page je peux encore faire l'update mais si je n'arrive pas à intrecepter la fermeture de la page ou le départ pour un autre site ?
Comment mettre à jour la table dans ce cas là ?
09/02/2009, 09h58
rems033
Avec la fonction "onunload" dans ton tag body tu rediriges vers un script qui met à jour ta BDD, tu as essayé ?
J'ai testé avec ceci :
Code:

1 2 <body onunload="javascript:alert('good bye !');">
et lorsque je tape une nouvelle adresse dans la barre d'url, j'ai bien le message
09/02/2009, 09h59
Doksuri

tu peux faire un script qui tourne en boucle toutes les X minutes et qui regarde le timestamp de la derniere activitee du user.
ou alors tu peux detecter la derniere activitee du user quand un autre user navigue sur ton site
09/02/2009, 11h10
SpaceFrog

pour le onunload ou onbeforeunload (que j'ai mentionné dasn ma question) cela suppose une action client ...
si le onunload n'est pas declenché la table n'est pas mise à jour...

pour ce qui est d'un script qui tourner toutes les X minutes ??? on fait ça comment en php ???
Une action php est declenchée par une page porteuse ...
Il faut que j'attende que quelqu'un tape une page non ???
on peut lancer des actions 100% serveur sans intervention de user ????
09/02/2009, 11h14
rems033

Pour une tâche exécutée toutes les X minutes, il faut regarder du côté de CRON si tu as la main sur le serveur.

Pour le onunload, j'ai du mal comprendre ta requête mais il me semblait que dans tout les cas (changement de pages, fermeture d'onglet, fermeture d'appli) il fallait une intervention utilisateur et notemment pour le "départ vers un autre site"
09/02/2009, 11h27
SpaceFrog

le onunload ou onbeforeunload sert juste à lancer une fonction javascript qui appelle une page php et permet de mettre à jour la table...

Si il y a plantage coté client, c'est a dire que la fermeture du browser se fait avant le declenchement de l'evenement onbeforuneload ou onunload, la mise à jour ne sera pas faite ...

Pour le CRON je n'ai malheureusement pas la main sur tous les serveurs...
dans certains cas je pourrais croner ...
La question demeure pour les cas ou je ne peux pas croner ...

peut on envisager une page php que l'on ne lancerait qu'une fois et quoi tournerait en boucle ??? ça me semble un peu du bidouillage qui va occuper le serveur inutilement non ?
09/02/2009, 14h05
rems033

Si par plantage tu entends "crash" du navigateur, alors oui tu ne pourras pas mettre à jour ta BDD avec onunload.
Par contre des les cas de changements d'url directement dans la barre, fermeture de l'onglet, fermeture du navigateur, tu pourras mettre à jour ta BDD a l'aide d'onunload.

Citation:

peut on envisager une page php que l'on ne lancerait qu'une fois et quoi tournerait en boucle ??? ça me semble un peu du bidouillage qui va occuper le serveur inutilement non ?

N'est pas la finalité de CRON ?
Tout a fait raison pour l'occupation mémoire de ton serveur.
Par contre, techniquement je ne vois pas comment côté serveur automatiquement recharger le script sans CRON, je manque de compétences sur le coup probablement.

Alternative :
Il y a WebCRON mais il s'agit d'un service payant offrant une alternative pour les personnes n'ayant pas la main sur leurs serveurs.
09/02/2009, 18h09
kaymak

J'ajoute une autre solution, plus lourde cependant.

Si tu as ré implémenté les sessions via la bdd ect.
J'imagine que tu as du ré implémenter une fonction pour détruire l'information dans le sgdb lorsque la session est morte.
A ce moment, tu pourrais inscrire une liste de callback, et les appeller avec par exemple le contenu de la session.
Ensuite c'est au callback de se démerder pour nettoyer ce qui doit l'être.

Si le Si n'est pas vrai alors laisse tomber cette solution.

PS : n'ayant jamais ré implémenté la session j'ai un petit doute sur mon hypothèse de départ qui est de dire que php appel le callback de fin de session même lorsque l'action ne vient pas de session_destroy()

a plus