Bonjour tout le monde,  
voila je me tourne vers vous aujourd'hui car j'ai besoin d'un petit conseil ou d'une petite astuce.
 
J'ai besoin de lancer une session_destroy à la fermeture de mon site, ou à la fermeture de mon navigateur.
Vu que j'include l'ensemble de mes pages dans une unique page mère, je pensais utiliser la fameuse fonction onunload allant dans le body de mon index, mais malheureusement  cela ne fonctionne pas.  
 
J'aimerais donc savoir si l'un d'entre vous à une solution pour lancer un session_destroy à la fermeture du site.
J'ai cherché un peu partout, n'est trouvé que la très incompréhensible session_set_save_handler http://fr2.php.net/manual/fr/funct [...] andler.php  
 
Voila, est ce que quelqu'un à déjà eu à faire ce petit bout de code qui semble tout simple et qui doit l'être par ailleurs.  
 
Merci d'avance les gens ^^ @ bientôt j'espère
 

Javascript est biensur ton ami pour faire ce genre de chose. Il est clair que c'est possible. Fermerture du navigateur => appel d'une fonction php avec js (ajax ?) => fermeture de session en php. Pour le schéma c'est ça, tout du moins c'est ce que j'aurais fait.
 
Pour le concret, soit google est ton ami. Soit tu peux chercher un site de merde (ou de porn) qui t'envoie un message js quand tu ferme la fenetre, tu devrais pouvoir te servir de cet appel en l'arangeant à ta sauce.

regarde du cote de onbeforeunload en javascript

Je vois pas pourquoi vous voulez mettre du JS pour un truc dont on veut un résultat sûr (donc on oublie le JS) alors qu'en plus il y a déjà ce qu'il faut d'intégré à php.
 
 
session.cookie_lifetime = 0 dans le php.ini et la session est euthanasiée à la fermeture du navigateur. C'est la valeur par défaut.
 
Donc en comportement par défaut, à la fermeture du navigateur, le cookie de session est poubellisé et donc à la prochaine ouverture une autre session est servie avec pour conséquences plus d'identification si ces paramètres sont stockés dans la session

et ca fonctionne chez toi ?

perso les sessions ne sont pas poubellisées lors de la fermeture de mon navigateur, j'ai surement mal paramétré mon wamp, mais vu que je n'aurais pas accès au php.ini de l'hébergeur, je ne sais pas si c'est la meilleure solution...
Je vais quand même regarder s'il est possible de définir cette petite modification de session.cookie_lifetime à l'entrée du site, sans avoir à toucher au php.ini, sinon bah j'ai du me planter dans mon script javascript, je faisais appel à une page qui me killait mes sessions, mais ça ne fonctionnait pas...
 
Je vais voir aussi du coté de onbeforeunload, pour voir ce que ça donne, et je vous tiens au courant de toute cette petite panoplie de solutions ^^
 
Merci encore ^^
 
Edit : Et si je défini un session_cache_expire(); à 30 minutes par exemple, ça pourrait etre sympa aussi. En fait les mecs systèmes veulent juste que la sessions meurent au bout d'un moment, mais c'est moi qui avait choisi de la faire mourrir (la pauvre) à la fermeture du site, mais bon au bout de 30 minutes ça peut etre bien aussi. Par contre si je comprend bien, tant que le site est utilisé, le cache expire n'est pas activé? Enfin ce que je veux dire, c'est que si on ce ballade pendant 2h sur le site on sera pas obliger de ce loguer 4 fois si?    
Merci pour tout ^^

Flo850 => ouais ça marche, on a parfois l'impression que ça déconne mais c'est juste des histoires de cache ou il reste un truc ouvert (faut que toutes les fenêtres soient fermées ie le processus du navigateur tué)
 
Micfont999 => en fait c'est toujouts un peu obscur de prime abord.  
session.cookie_lifetime est la durée de vie du cookie de session. Passé ce délais le cookie est invalide donc l'identifiant de session perdu. Mais la session existe toujours sur le serveur si tu la détruits pas et tant que le garbage collector (mécanisme interne de nettoyage des fichiers de session) n'est pas passé faire un  tour.
Les valeurs session_cache_* se rapporte à la manière dont les entêtes concernant le cache des pages contenant des sessions sont gérées. Au final pas grande interaction avec la session elle même.
 
Les sessions meurent au bout d'un moment toutes seules. Par défaut c'est 1440s avec la directive session.gc_maxlifetime qui définit le temps max entre la dernière modification et le passage du GC. C'est plutôt ça qui t'intéresse. Et là la session est physique supprimée mais pas automatiquement, lors du passage du GC qui se déclanche selon des probabilités définies dans le php.ini. Donc à vide ton système risque de pas se nettoyer tout seul si tu es seul, te fie pas à ça
 
session_set_cookie_params() te permet de modifier les valeurs courantes.
 
Une dernière chose, rien ne t'empêche en plus de gérer toi un délai en stockant en session le timestamp de la dernière action. Tu définis une valeur max et calcule la différence toi même et zou tu tues la session quand tu veux Mais le système intégré s'il est bien configuré doit suffir
 

Merci leflos d'avoir pris le temps de m'expliquer toutes ces petites choses c'est sympa  
Bon finalement le patron veux que je mette en place la destruction à la fermeture du site (même pas du navigateur mais de l'onglet par exemple), donc je vais voir par rapport à session.cookie_lifetime si il gère les onglets, sinon bah je vais passer par du JS je crois :s  
 
merci encore pour tout, je reviens si je re rencontre un bug par l'un de ces deux moyens, ce qui à mon avis sera le cas ^^

et bin je pensais pas que ce serais autant la misère de faire un script pareil ... onUnload ou unBeforeUnload est déclenché à chaque changement de page, c'est le gros bordel... c'est logique d'ailleur en soit, mais alors la je vois vraiment pas qu'elle autre solution je peux utiliser.. parce que session.cookie_lifetime est déclenché qu'a la fermeture du navigateur complet (au kill du processus du navigateur, donc si on ferme l'onglet ça ne fonctionne pas ) ...  
 
c'est quand même étrange de ne trouver aucune personne ayant déjà fait cette fonctionnalité.  
La seule solution serait de mettre tout dans une grosse frame, mais c'est hors de question, ça serait un travail beaucoup trop lourd ...
 
Vous auriez une idée lumineuse et brillante à me conseiller?
Merci à tous ceux qui ont déjà pris la peine de m'aider..

Techniquement parlant, quand tu fermes un navigateur, rien ne permet à Apache de le savoir avec du simple HTML ou PHP (sauf à configurer le lifetime avec un cookie comme expliqué). Vu que tu n'as pas accès au PHP.INI je ne vois qu'une solution AJAX ou JavaScript.
Ta question est quand même intéressante

Mais qu'est-ce que vous sortez ajax à tout bout de champs alors que ça sert absolument pas à ça

Bonjour  
Pour le moment j'ai mis le système de déconnexion à la fermeture du navigateur, en attendant d'avoir le temps de faire quelques recherches sur comment détecter la fermeture d'un onglet sur les navigateurs, ça doit être possible ^^  
 
SInon pour ajax je ne connais pas suffisament pour savoir s'il sert à quelque chose ou non dans cette affaire ^^  
 
En tout cas, merci pour tout ^^

Ca ne te sera d'aucune aide de toutes manières ajax ici...

Soit j'ai rien compris aux principes d'AJAX ou alors j'ai zapper un point important du sujet ?

Qu'est ce que l'AJAX pour toi à par un produit ménager

 
Va lire de la doc (ou ne serait-ce que http://en.wikipedia.org/wiki/AJAX) et tu verras toi même laquelle de ces 2 options est juste

une pub avec Carmen

Je suis loin d'être expert dans le domaine, mais ne serait-il pas judicieux de forcer PHP à transmettre l'identifiant de session via l'url plutot qu'un cookie ? La fermeture de l'onglet (et donc, par extension, de l'URL) devrait mettre un terme à la session courante (du moins, du coté client).  
 
Si quelqu'un peut confirmer ou infirmer ?
 
[Edit : après consultation de la doc, les directives session.use_cookies et session.use_trans_sid du php ini (via un setenv) devraient t'aider. Pour des raisons de sécurité, je pense qu'il serait utile de limiter la durée d'une session dans le temps également (pour éviter le bookmarking de l'url, par exemple). Cf. ce qui est proposé dans les premiers posts de ce topic, en complément de ma proposition, si elle s'avère adéquate]

   
http://en.wikipedia.org/wiki/AJAX)
 
 
http://en.wikipedia.org/wiki/AJAX)

(double post)
 
 

 
Si sur le principe tu pourrais éventuellement avoir raison, dans la pratique c'est qqch qu'il faut bannir sans aucun scrupule (quitte à crucifier toute personne disant le contraire) à cause des failles de sécurité impressionnantes que ça ouvre

Bien que je comprenne que cette solution soit moins sûre (dans le sens où l'identifiant de session est disponible très (trop) symboliquement dans l'url, et non cachée dans un cookie tout de même accessible), je ne vois pas le "gouffre" de sécurité. Peux-tu détailler un peu ton propos stp ?  
 
Merci

En bref :
 
http://shh.thathost.com/secadv/2003-05-11-php.txt

Ah, si ce n'est que ça ! Ce truc là a été corrigé depuis très longtemps maintenant !
Et ce n'est pas délibérément lié à ma solution, mais juste à l'usage habituel des sessions. Tout navigateur refusant les cookies pouvait forcer ce comportement de PHP.  
 
 
 

Heu corrigé corrigé ... À ce que j'en sais (et je vois pas à vrai dire comment les dev pourraient corriger ça), tu peux toujours utiliser le truc du SID dans l'url ...
Tu voles le SID de qqn (via par exemple le referer) => Tu lui piques sa session.
Conclusion => On utilise pas le SID dans l'url et on fait gaffe à comment on utilise les cookies pour éviter tous les problèmes de cookies forgés & co

Le lien que tu as donné concernant des soucis d'injection de code dans l'identifiant de session. Ce n'est pas pareil que de "voler" l'identifiant de session de quelqu'un. Concernant le vol de l'identifiant, sache qu'il est tout aussi faisable qu'il soit dans l'url ou dans un cookie. Par ailleurs, je rappelle qu'utiliser les cookies n'exempte pas l'utilisation du SID url par PHP ! Tout dépend de la configuration du client.  
 
Tout au plus, à l'encontre du SID url, c'est plus facile de faire une erreur en donnant le lien d'une page à quelqu'un et en incluant l'identifiant de session.  
 
C'est pour cette raison que je suggérais :  
1. De timestamper manuellement la session, afin de ne pas la conserver trop longtemps (en plus de la solution proposée in-muros par PHP).  
2. D'éventuellement mémoriser l'adresse IP du créateur de la session courante, afin de s'assurer qu'aucune autre personne ne peut utiliser cette même session durant la même "session de surf" (moyennement le fait que les IP soient différentes).

Je pense que ce débat tourne en rond et que la solution a été donnée à mon sens: session.cookie_lifetime=0 gère le cas où il y a fermeture + session.gc_maxlifetime (ou calcul maison avec stockage dernier timestamp en session si peu d'utilisateurs et pas de prise sur php.ini pour config GC) avec valeur petite mais permettant un surf entre 2 pages pour le reste (quelques minutes).
 
Ca permet dans tous les cas d'avoir la session morte au mieux à la fermeture du navigateur au pire quelques minutes après la dernière page consultée dans tous les cas. Vouloir plus de façon fiable (c'est à dire qui marche à tous les coups) c'est impossible et ça serait même stupide de se borner à faire un bidouillage pour avoir mieux parce que le système fait que ça sera pas mieux
 
PS: pourquoi pas pour l'IP dans ce cas mais faut stocker ça en base alors

Attention avec l'IP distante du visiteur : certains FAI (AOL) utilisent des batteries de proxies qui font qu'un visiteur n'a pas forcément toujours la même IP.

Leflos> Je proposais une solution qui détruirait la session à la fermeture d'un onglet, et non pas seulement à la fermeture du navigateur, comme cela avait été demandé. Et, à mon avis, cela doit passer par le SID url. Enfin, quoiqu'il en soit, la personne à l'origine du post dispose de suffisamment de pistes que pour trouver son bonheur parmi toutes les réponses :-)
 

Ah oui je les avais oublié ceux là...
 

Oui mais comme quelqu'un l'a dit c'est une utopie d'utiliser les SID dans les url parce que c'est s'exposer à de graves ennuis.