Discussion :

[DarkChamallo]

Bonjour,

il y a quelque chose que je ne comprend pas (ou que je ne sais pas) malgré mes recherches sur internet :

- les sessions lancées expirent-elles obligatoirement au bout de X minutes ou bien sont-elles prolongées à chaque fois que je recharge une page et donc tant que j'utilise l'application web la session n'expire jamais ?

Perso (sur un hébergement où je ne peux pas régler php.ini) je ne souhaite pas qu'une session expire : mon appli (privée) oblige l'acceptation des cookies et du javascript et je gère moi-même la déconnexion automatique au bout de X minutes avec JS. Je n'ai pas envie d'une interruption intempestive tout ça parce qu'une session PHP décide d'expirer sans que je lui demande...

Quelqu'un peut-il m'éclairer ?

Merci !

[Fladnag]

La durée d'une session dépend de 2 choses :

* La durée de vie du cookie (située sur le poste client)
Cette durée est parametrable lors de l'ouverture de la session avec un parametre optionnel.
Par defaut, la fermeture du navigateur invalide le cookie, mais tu peux en principe lui donner une valeur de 500 ans ^^

* La durée de vie du fichier contenant les variables de session (situé sur le serveur)
Là c'est beaucoup plus dur. Une session n'est PAS faite pour durer.
En général ce fichier de quelques ko a peine est situé dans le repertoire /tmp du serveur, là ou il y a les fichiers de sessions de tout le monde. (Meme si certains hebergeurs "compartimentent" en les stockant dans l'arborescence du site... ca permet de les compter dans l'espace disque ^^
Ce que je veux dire c'est que cette session est un fichier TEMPORAIRE. Du coup, si l'administrateur systeme du serveur a besoin de faire de la place, il peut tout a fait faire le ménage et supprimer ces fichiers.
En général ils sont intelligents et ils commencent par les plus anciens, mais rien ne les y oblige ;o)

En clair, une session n'est pas l'endroit ou stocker "ad eternam" des données sensibles. Utilise plutot une base de données a la place, c'est fait pour ca ;o)
(Quitte a charger/decharger les infos de la bdd de et vers la session si tu veux pas réécrire toute ton appli !)

[12monkeys]

Bonjour

Les sessions dans leur configuration par défaut utilisent les cookies sans date d'expiration, c'est à dire que votre session va durer aussi longtemps que dure le cookie ; le cookie disparait dès qu'on ferme le navigateur, en retournant sur le site, le cookie n'existant plus, php va créer un nouveau cookie et donc une nouvelle session...

Ensuite le fichier de session est lui effacé indépendamment du cookie, par php qui lit le répertoire des sessions et efface les fichiers de session ayant expirés : les fichiers expirés sont ceux qui ont un âge en secondes plus important que la valeur de session.gc_maxlifetime.

[DarkChamallo]

Merci pour les réponses Mais... je reste dans le flou car j'ai l'impression que vous dites l'inverse chacun :

Les sessions dans leur configuration par défaut utilisent les cookies sans date d'expiration, c'est à dire que votre session va durer aussi longtemps que dure le cookie

Une session n'est PAS faite pour durer.

En fait je cherche à savoir comment faire pour que tant que l'utilisateur ne ferme pas son navigateur ou ne clique pas sur se déconnecter : il n'ait pas de contrainte de temps.

Je veux gérer la déconnexion automatique moi-même. Mais si au bout de 20 minutes je lui demande s'il est toujours là et qu'il me répond oui... et que 2 minutes après php s'en contre fiche et lui claque la porte au nez, ça le fait pas , y-a-t-il une procédure particulière pour obtenir cela ?

[Fladnag]

http://fr3.php.net/manual/fr/functio...kie-params.php

Tu peux régler la date d'expiration du cookie.

Maintenant si tu veux que ta session dure 3 ans sans risque, là c'est impossible, le fichier sur le serveur pourra être supprimé avant.
(En général 1 semaine ca marche, mais ca depend des hebergeurs ;o)

A noter qu'en PHP tu ne demande RIEN au client, c'est toujours lui qui vient de voir et qui te dit "coucou je suis toujours la !"

En conséquence, tu as le fonctionnement suivant :
* Le client ouvre une session avec une durée de vie de 24h
=> Le serveur créé un fichier sur le serveur (contenant les variables de session)
=> Le client créé un cookie sur sa machine (contenant l'ID de session)
* Le client ferme son navigateur sans cliquer sur "Deconnecter"
...
* 25h plus tard :
=> Le cookie EXISTE TOUJOURS sur le PC client
=> Le fichier sur le serveur existe aussi probablement (là j'en suis moins sur) ou il aura été supprimé par une sous routine du serveur.
...
* 3 jours apres, le client se reconnecte sur le site.
=> Le navigateur détecte qu'il y a un cookie expiré : il le supprime sur le poste client
=> (Eventuellement, il indique au serveur de supprimer son fichier mais j'en suis moins sur aussi ^^)

[12monkeys]

Non, je pense que nous disons bien la même chose tous les deux : une session va durer aussi longtemps que dure la navigation de l'internaute (cookie) sauf à ce que la durée d'inactivité de l'internaute dépasse la valeur de session.gc_maxlifetime (et là encore l'effacement du fichier de session va dépendre des probabilités).

Ce que veut dire Fladnag je pense, c'est que les fichiers de session vont être effacés après un moment, contrairement par exemple aux cookies auxquels tu peut donner une durée de vie de 50 ans...

Comment php fait-il pour effacer les fichiers de session : à chaque lancement d'une session php tire un nombre au hasard entre 0 et 99, si ce numéro est inférieur à la valeur de session.gc_probability, alors php lit le répertoire de stockage des sessions et efface tous les fichiers de session qui ont expirés.

Je te précisais dans mon autre message que les fichiers expirés sont ceux qui ont un âge en secondes plus important que la valeur de session.gc_maxlifetime, je suppose que pour l'âge de la session php tient compte du dernier accès à ce fichier (ou de la dernière ecriture/lecture ?)

Edit : encore grillé

[Fladnag]

Edit : encore grillé

Mais non, j'ai appris plein de trucs, je savais pas comment fonctionnait le garbage collector de php ;o) Merci !

[DarkChamallo]

Waouu, j'ai arrêté mon reply en voyant que j'avais reçu une nouvelle réponse...

Donc, merci Fladnag pour le lien , je vais l'exploiter et merci 12monkeys pour tes explications.

Perso, je vais garder en vie le cookie 10 heures environ histoire de couvrir une journée de travail.

Mais concernant la déconnexion je fais apparaître au bout de 20 minutes d'inactivité une alerte... et si au bout de 5 minutes l'utilisateur n'a pas cliqué sur le bouton annuler de cette alerte -> il est déconnecté. Si en revanche il clique sur le bouton annuler il a à nouveau 20 minutes d'inactivité autorisées ça vous fait froncer les sourcils ou pas ? A la limite il faudrait redemander un mot de passe pour annuler (houla il va falloir que je fasse communiquer JS et php )?

[Fladnag]

20mn d'inactivité... comment ? Avec du Javascript ? Là c'est faisable... sauf que s'il a fermé brutalement son navigateur, il n'y aura pas de javascript ^^
Et s'il revient ensuite sur le site, il sera a nouveau reconnu, puisque le cookie sera toujours valide.

Bref, un utilisateur qui veux faire une pause d'1h n'aura qu'a fermer son navigateur et le rouvrir ensuite, ton site n'y verras que du feu !

Sinon, 20mn ca me parait super court... pour une raison toute simple, les gens mangent a midi ;o)
Donc a moins de compter sur eux pour se deconnecter/reconnecter a la mi journée, ils partiront tous en timeout entre midi et deux.

(Apres ca depend des entreprises... mais là ou je suis, une pause café de 26mn... c'est envisageable ^^)

En fait il faut déterminer quel est ton but.
Deconnecter les utilisateurs inactifs ? Pourquoi ? L'application contient des données "sensibles" ? Les utilisateurs ne verrouillent pas leur PCs ? Des personnes non autorisés peuvent approcher les PCs ?

Si les données sont vraiment sensibles, met un timeout de 5 ou 10mn max.

Sinon mieux que "deconnecter" l'utilisateur, si tu en as la possibilité, "sauvegarde" l'intégralité de la page dans une table spéciale (champs saisis envoyés en javascript, données de sessions, etc...) et réaffiche un formulaire de connection avec demande de login/pass. Ainsi, ca "verrouillera" l'application comme un écran de veille. La saisie d'un login/pass correct restaurera le dernier écran comme s'il ne s'était rien passé (c'est un peu complexe a faire mais a coeur vaillant... rien d'impossible ^^)

[12monkeys]

Mais non, j'ai appris plein de trucs, je savais pas comment fonctionnait le garbage collector de php ;o) Merci !

De rien

Perso, je vais garder en vie le cookie 10 heures environ histoire de couvrir une journée de travail.

Mais concernant la déconnexion je fais apparaître au bout de 20 minutes d'inactivité une alerte... et si au bout de 5 minutes l'utilisateur n'a pas cliqué sur le bouton annuler de cette alerte -> il est déconnecté. Si en revanche il clique sur le bouton annuler il a à nouveau 20 minutes d'inactivité autorisées ça vous fait froncer les sourcils ou pas ?

Si tu veut tu peut aussi définir un gestionnaire de sessions personnalisé : voir session.save_handler et session-set-save-handler je n'ai jamais utilisé, donc je peut pas te dire si c'est compliqué ou pas...

Pour le cookie, de toute façon tant que l'internaute laisse son navigateur ouvert le cookie reste valide, donc mettre une vie au cookie de 10 heures je ne vois pas trop l'intérêt...

Par contre pour le reste je suis assez d'accord, si l'internaute doit effectuer une action toute les 20 minutes, ça garantie le maintient de sa session (encore une fois pour peu que session.gc_maxlifetime soit supérieur à cette intervalle) car il semble bien que l'âge du fichier de session soit calculé en fonction du dernier accès, voici ce que dit le manuel :

Si vous utilisez le gestionnaire de sessions par fichier, qui est fourni par défaut, votre système doit garder la trace des dates de dernier accès aux fichiers...

[DarkChamallo]

20mn d'inactivité... comment ? Avec du Javascript ?

Oui, en fait le JS que j'ai fait ne s'occupe que d'afficher une alerte (un peu à la Ajax translucide plein écran) après 20 minutes d'inactivité. 5 minutes plus tard -> redirection vers un script suicidaire qui déconnecte. Si l'utilisateur ferme le navigateur = plus de session php donc il faut se reconnecter, encore heureux car :

L'application contient des données "sensibles" ? Les utilisateurs ne verrouillent pas leur PCs ? Des personnes non autorisés peuvent approcher les PCs ?

Oui, oui et oui 'sont pas exemplaires les bougres

12monkeys merci pour les liens je vais potasser tout ça

Et donc je ne vais pas mettre de durer de vie puisqu'effectivement le but n'est pas de les maintenir mais seulement d'empêcher qu'elles se terminent intempestivement... mais tant que l'utilisateur utilise la durée de la session est reconduite automatiquement n'est-ce pas ? Donc c'est le JS qui va gérer la déconnexion et au pire au bout de 24 minutes les sessions seront mortes. C'est bien ça ?