session.gc_maxlifetime ou session.cache_expire ?

**zeflex** · 09/02/2011, 23h41

Bonsoir,

Je cherche à prolonger le temps d'ouverture d'une session à chaque changement de page dans une zone administration, afin que l'utilisateur étant loggué le reste tant qu'il ne cliques pas sur un loggout.

Actuellement, j'ai mis en tête de chaque page :

Code :

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

1
2
3
 
ini_set('session.gc_maxlifetime', 60*60);
session_start();

Mais comment prolonger d'une heure le temps de la session à chaque changement de page ? Via un "session.cache_expire" ?

Merci.

**sabotage** · 10/02/2011, 00h08

la vie de la session recommence a chaque demarrage de session.

**zeflex** · 10/02/2011, 18h47

Ok mais je fais un petit essai et je ne comprends pas pourquoi la valeur de la session est toujours en mémoire. Dans mon cas précis, sa valeur devrait changer au refresh de la page non ?

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
 
<?php
ini_set('session.gc_maxlifetime',5);
session_start();
 
if ( !isset($_SESSION['stq']) ) {
$_SESSION['stq'] = time();
}
?>
<html>
<head>
<title>TEST</title>
<META HTTP-EQUIV="Refresh" CONTENT="10">
</head>
<body>
<?php echo time(); ?> - test - <?php echo $_SESSION['stq']; ?>
</body>
</html>

**sabotage** · 10/02/2011, 20h40

Quand tu fais un session_start() :
1 - PHP rafraichit la session demandée
2 - PHP décide de déclencher ou non (selon la probabilité configurée sur le serveur) le "nettoyeur de session".

Si tu es tout seul sur le serveur, ta session ne sera donc jamais supprimée.

Si tu lances ton script avec deux sessions différentes, chacun va supprimer la session de l'autre.

**zeflex** · 10/02/2011, 22h18

Dans le cas où j'arriverai sur une page d'identification, ma deuxieme authentification écraserait la première oui.

Hors là, ce qu'il se passe c'est qu'un collègue à moi se loggue sur une page qui l'amènes ensuite sur un formulaire et si il ne crée aucune activitée sur celle ci (remplissage du formulaire) ; il sera déconnecté de sa session d'authentification au refresh de cette page par ex au bout d'un temps N.

Dans l'exemple que j'ai cité j'ai quand même du mal à comprendre pourquoi la valeur de la session ne changes pas au refresh vu qu'on demandes à la session de ne durer que 5 sec.

**sabotage** · 10/02/2011, 22h24

Je te l'ai expliqué ; je ne parle pas du tout de session qui s'écrasent.

**RunCodePhp** · 11/02/2011, 07h47

Salut

Au lieu de vérifier ça avec une variable de session, essai plutôt d'afficher l'ID de session, et aussi ce que contient le cookie de session.

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
 
<?php
ini_set('session.gc_maxlifetime',5);
session_start();
?>
<html>
<head>
<title>TEST</title>
<META HTTP-EQUIV="Refresh" CONTENT="10">
</head>
<body>
<?php
echo 'session_id() : '.session_id();
$cookie_params = session_get_cookie_params();
?>
<pre>
<?php
print_r($cookie_params);
?>
</pre>
<?php
echo 'durée de vie du cookie : '.date('d/m/Y H:i:s', $cookie_params['lifetime']);
?>
</body>
</html>

session.gc_maxlifetime ça concerne le ramasse miette (Garbage Collector), donc la suppression du fichier dépend de la formule de ce mécanisme.

En se qui concerne le durée de vie du cookie de session, normalement c'est session.cookie_lifetime qui par défaut vaut 0, soit lorsque le navigateur sera fermé.
Dans cette condition, et bien le cookie de session une fois créé serait toujours valide, et coté serveur lors de chaque refresh, la session serait à nouveau récupérée vu que le fichier serait toujours là.

Ceci dit, j'ai aussi une petite hésitation, alors ce test avec ces informations devrait nous rafraichir la mémoire.

Mais pour info, de mon coté j'ai toujours pris soin de définir explicitement la durée de vie du cookie et aussi celle de la session (les sessions sont dans une Bdd, et il y a un champ date d'expiration).
En somme, on évite le coté trop automatique de cette gestion des sessions/cookies.

Pour tes essai, exploite la fonction session_set_cookie_params() ou alors setcookie() afin d'y mettre la durée de vie que tu veux.

Donc si on mets comme durée time() + 5 au cookie, et bien normalement au bout de 10 secondes sa date sera expirée, le cookie ne sera plus renvoyé vers le serveur, donc plus de cookie, et au bout le serveur devrait recréer une nouvelle session.

**zeflex** · 11/02/2011, 20h15

Oui mais ce que je voudrais éviter de faire dans mon systeme c'est de passer par des cookies via le navigateur du visiteur.

Voici tout de meme ce que j'obtiens avec plusieurs refresh de ton script :

session_id() : 2aipgl9h5pn6fg0bmeng2glh87

Array
(
[lifetime] => 0
[path] => /
[domain] =>
[secure] =>
[httponly] =>
)

durée de vie du cookie : 01/01/1970 01:00:00

Rien ne changes, le session id reste toujours identique.

**RunCodePhp** · 11/02/2011, 22h20

Oui mais ce que je voudrais éviter de faire dans mon systeme c'est de passer par des cookies via le navigateur du visiteur.

Et pour quelle raison ?

Faut savoir que le principe de la gestion des sessions repose totalement :
- Soit sur un cookie, c'est à dire que les échanges du couple nom/id de session se fait via 1 cookie.
- Soit en URL, c'est à dire que les échanges du couple nom/id de session se fait via tous les liens/formulaire (toutes les URLs) dans toute la page.

Je ne pense pas qu'il y ait un autre moyen que ces 2 là.
Le moyen le plus sécurisé reste via un cookie, pour la simple raison que les échanges sont dans les entêtes, donc un peu caché alors que via les URLs elles sont totalement visibles (entre autre).

Rien ne changes, le session id reste toujours identique.
[lifetime] => 0

Rien ne change car tu n'as rien fais de particulier sinon de constater que la valeur de la date d'expiration du cookie est belle est bien de 0.
C'est ce que j'expliquais : 0 correspond à -> "jusqu'à fermeture du navigateur"
Soit très longtemps donc normal que la session soit encore valide.

Donc bis : Il faut que tu définissent toi même une date d'expiration au cookie.

**zeflex** · 14/02/2011, 18h24

Merci de vos réponses.

Je penses ne pas être très loin d'avoir ce dont j'ai besoin.

Actuellement j'ai ceci :

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
 
<?php
ini_set('session.gc_maxlifetime',5);
session_start();
 
if ( empty($_COOKIE["save_login"]) ) {
	setcookie("save_login",time(),time()+(20),"/admin/v2/","www.ndd.com");
	echo 'mis en place !<br/>';
}
 
?>
<html>
<head>
<title>TEST</title>
<META HTTP-EQUIV="Refresh" CONTENT="5">
</head>
<body>
<?php
echo 'session_id() : '.session_id();
$cookie_params = session_get_cookie_params();
?>
<pre>
<?php
print_r($cookie_params);
?>
</pre>
<?php
echo 'durée de vie du cookie : '.date('d/m/Y H:i:s', $cookie_params['lifetime']).'<br/>';
 
if ( !empty($_COOKIE["save_login"]) ) {
	echo 'cookie valide jusqu\'au : '.date('d/m/Y H:i:s', $_COOKIE["save_login"]);
}
?>
</body>
</html>

Donc effectivement le cookie est setupé pour 20sec.
En revanche l'instruction

ini_set('session.gc_maxlifetime',5);

ne sert apparemment à rien, je ne vois pas de différence avec ou sans ... De plus les valeurs de $cookie_params restent toujours identiques.

Est ce normal ?

**RunCodePhp** · 16/02/2011, 08h31

C'est le principe de base du fonctionnement des sessions qui n'est pas bien compris à mon sens.

Dans ton dernier essai, tu créé un cookie avec comme nom "save_login" avec comme valeur le temps en court, etc ...
Mais tout ça est caduque car ton cookie est un tout nouveau cookie, il n'a strictement aucun rapport avec celui de la session.
Le principe de tout cela repose (par défaut) sur 1 fichier de session correspondant à 1 cookie bien distinct.

Quand j'avais dit qu'il fallait définir soit même une date d'expiration au cookie, il faut que ce soit fait sur le cookie correspondant à la session.

Par défaut, le nom de la session est : PHPSESSID
Donc le cookie aura lui aussi le même nom : PHPSESSID
Fait un echo session_name() pour connaitre le nom de la session.
Et la valeur du cookie doit obligatoirement avoir la même valeur que l'identifiant de la session (valeur de session_id)
Il faut que les 2 correspondent sinon ça ne fonctionnera pas.

Il n'y a donc pas créer de nouveau cookie, il faut juste que tu définisse un temps au cookie de session correspondant.
Pour faire ça il suffit de faire :

Code :

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

1
2
 
setcookie(session_name(), session_id(), time() + 5, '/', 'domaine.com');

Et oubli cet histoire de session.gc_maxlifetime, car ce n'est pas ça qui te cause problème.

Aussi, au niveau logique, il faut tout le temps redéfinir ce temps d'expiration au cookie, et pas seulement s'il n'existe pas.
Le principe, la logique est théoriquement la suivante (dans un fonctionnement normal) :
SI le cookie n'existe pas : On le crée + on lui défini un temps d'expiration (maintenant + n secondes)
SI le cookie existe : On reconduit sont temps d'expiration (maintenant + n secondes) (ce qui revient au même que le créer, même code).

Si tu ne reconduit pas le temps d'expiration du cookie lorsqu'il existe, ça devient plus du tout pratique, car si derrière il y a un mécanisme d'identification par exemple, il va être fréquent que les utilisateurs devront se ré-identifier car le délai aura été expiré.
Bref ... dans tous les cas il faut redéfinir le cookie de session.

Si le temps d'expiration du cookie est vraiment dépassé, même si le temps a été reconduit.
- En 1er le navigateur va détruire le cookie sur la machine de l'utilisateur
- Puis le navigateur ne va pas rajouter dans l'entête de la requête HTTP le cookie.
- Donc le serveur recevant cette requête HTTP, ne voyant pas de cookie, et bien au session_start() une nouvelle session sera créé (nouvel identifiant).

Ton problème, qui est le même depuis le début, c'est que la valeur du temps d'expiration du cookie est de 0 (fermeture du navig.), donc comme le navigateur n'a pas été fermé, le cookie est encore valide, donc à chaque fois rajouté dans l'entête de la requête HTTP.
Le serveur recevant ce cookie, détecte un fichier de session correspondant (le ramasse miette ne l'ayant pas encore supprimé), le récupère, donc conserve cette persistance, la même session.

En espérant que tout ceci t'aide à mieux comprendre ton problème, et le fonctionnement des sessions/cookie.

**sabotage** · 16/02/2011, 11h07

Et oubli cet histoire de session.gc_maxlifetime, car ce n'est pas ça qui te cause problème.

Je ne suis pas d'accord.
Vous êtes en train de faire des contournements pour faire fonctionner une situation anormale (un seul client sur le serveur).
Dans la vraie vie, c'est bien ce paramètre qui va déterminer a quel moment on tue la session.

Je ne vois en tout cas pas l'intérêt de forcer la fin de vie de la session depuis le client en utilisant le cookie.

**RunCodePhp** · 16/02/2011, 11h32

Envoyé par sabotage

Dans la vraie vie, c'est bien ce paramètre qui va déterminer a quel moment on tue la session.

En est tu vraiment sur ?
Je ne vois vraiment pas le raaport du fait que ce serait qu'1 seul client.
(c'est pas pour contre dire, juste pour comprendre, on est d'accord

).

Si c'était le cas, au session_star() une nouvelle session aurait dû être crée, or ce n'est pas le cas.

Pour ma part son problème vient du faite que par défaut la valeur du temps d'expiration du cookie est 0, c'est à dire lors de la fermeture du navigateur.
Dans ces essais il n'y a pas de fermeture du navigateur, donc le cookie reste valide tout le temps.

L'autre aspect, c'est qu'apparemment Php ne fait pas (ou ne ferait pas) une comparaison/soustraction entre le date de création du fichier de session (ou date de dernière modification) et le délai d'expiration fixé au session.gc_maxlifetime.
Si c'était le cas, le fait de définir 5 secondes, Php ne devrait pas récupérer la même session (vu que la demande se fait au bout de 10 secondes), donc ignorer ce fichier et en créer un autre, autre identifiant.

Ou alors, peut être que la modification cette directive (le gc) n'est pas prise en compte.
Ou peut être que 5 secondes c'est trop coup, poserait problème à Php, va savoir.
Faudrait peut être faire d'autres essais.

Personnellement je ne vois pas autres choses.

@sabotage
D'ailleurs, c'est cet aspect là qui à aujourd'hui je ne sais plus, car ça fait longtemps que j'ai une gestion des session personnalisée, dans la Bdd, etc ...
Donc selon toi, est ce que par défaut Php fait une analyse de la date du fichier de session par rapport au délai du session.gc_maxlifetime ?

**sabotage** · 16/02/2011, 11h51

J'ai expliqué pourquoi au dessus : quand il n'y a qu'un seul utilisateur sur le serveur, sa session n'est jamais détruite.
Quand on fait des tests tout seul, on ne reproduit pas une vraie gestion des sessions.

**RunCodePhp** · 16/02/2011, 12h08

J'ai expliqué pourquoi au dessus

Humm, non, pas vraiment.

Ma question était pourtant très simple, et c'est soit oui, soit non (soit Php fait une comparaison ou non).

Bon, au feeling comme ça, et en me basant sur ces essais, j'ai tendance à dire que Php n'analyserait pas cette date de création du fichier de session par rapport au délai fixé dans le session.gc_maxlifetime pour décider de récupérer ou non le fichier (la même session).

A mon sens, il faut attendre que le ramasse miette soit déclenché pour que le fichier soit détruit.

Et là, c'est vrai que s'il n'y a pas assez de fichiers de sessions, le déclenchement se fera dans très longtemps.
En faite, c'est une formule (magique) liée aux valeurs de 2 directives :
session.gc_probability (par défaut vaut 1)
session.gc_divisor (par défaut vaut 1000)
Alors là aussi je ne sais plus trop, mais il me semble que ça se déclenchera ici lorsqu'il y aura 1000 fichiers de session.

Faudrait que je refasse encore des essai pour me remémorer tout ça.

**sabotage** · 16/02/2011, 12h25

session.gc_probability et session.gc_divisor servent juste à définir la probabilité de déclenchement du ramasse miette.

Le ramasse miette se déclenche (ou non) lorsqu'une session démarre.
Mais comme je l'ai expliqué au dessus, il ne supprima jamais la session du script l'appelant puisqu'elle vient d'être actualisée.

Donc un utilisateur seul sur un serveur ne perds sa session que lorsque le cookie n'est plus valide.

**RunCodePhp** · 16/02/2011, 13h01

Le ramasse miette se déclenche (ou non) lorsqu'une session démarre.
Mais comme je l'ai expliqué au dessus, il ne supprima jamais la session du script l'appelant puisqu'elle vient d'être actualisée.

Ok, d'accord, mais n'empêche que ça ne répond pas à ma question qui pourtant est très précise :
Soit Php fait une comparaison, soit il n'en fait pas (ramasse miette déclenché ou pas, peu importe).

Pour ma part, ces essai démontrent que Php ne fait pas de comparaison : Le fichier existe encore car pas supprimé par le ramasse miette, le cookie est là dans l'entêtre, alors ceci suffit à Php de récupérer la session.

Et bien si tel est le cas, il y a un sacré problème dans ce principe là (par défaut), ça peu déboucher sur un dysfonctionnement du site (ces essai en est un), mais surtout, ça facilite un acte de vol de session.

Pour ma part, il est 100 fois mieux de fixer une date dans le cookie au lieu de 0 par défaut, car il sera au moins détruit par le navigateur au moment où il le faut.
Puis rajouter la même date d'expiration dans la session est aussi un bon moyen de renforcer ça.
C'est le cas de mon coté (pour exemple) car les session sont dans une Bdd, avec un champ "expiry", donc une session ne pourra pas être récupérée si sa date est expirée, même si elle est encore présente dans la Bdd.

Personnellement, je ne me vois pas exploiter les sessions autrement que comme ça, car il n'y plus du tout de hasard, et même si on fait des essai seul sur son poste en local.

**zeflex** · 17/02/2011, 00h15

Désolé du débat entre vous, j'ai un peu de mal à suivre.

Le seul truc qui me chagrines c'est que vous me dites que ma session est censée ne pas expirer car le lifetime est à 0 hors ma session se termines au bout d'un certain temps (environ une heure) si je ne rafraichit pas la page entre temps.

Je suis un peu perdu là dedans... Je pensais que je pouvais réellement me passer de gestion de cookies dans ce cas là précis (du moins, sur cette zone administration).

Je vais suivre la discussion de près voir une solution se présentes à moi

**sabotage** · 17/02/2011, 09h19

Soit Php fait une comparaison, soit il n'en fait pas (ramasse miette déclenché ou pas, peu importe).

Oui il le fait.

**RunCodePhp** · 17/02/2011, 12h34

Envoyé par sabotage

Oui il le fait.

Comme tu as dû le remarquer, je m'attendais vraiment à ce que tu réponde non.

Moi qui pensais avoir bien compris tout ça, je pige plus rien.

J'ai fais quelques essais (en local sur Xp, voir ma signature), c'est littéralement délirant, mais alors vraiment.

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
 
$files = array();
$files_expire = array();
$rep = 'D:/wamp/tmp/';
 
// Pour vérifier que le fichier expiré a été supprimé ou pas
$unlink = FALSE;
 
// Délai d'expiration perso
// (théoriquement devrait être l'équivalent du gc_maxlifetime
$life = 10; // 10 secondes
 
foreach (glob($rep.'sess_*') as $filename) {
    $filemtime = filemtime($filename);
    $expire = $filemtime + $life;
    //
    $files[] = array('nom' => $filename,
                     'time' => filemtime($filename),
                     'date' => date('d/m/Y H:i:s', filemtime($filename)),
                     'expire' => date('d/m/Y H:i:s', $expire));
    if ($expire < time()) {
        $files_expire[] = $filename;
        $unlink = unlink($filename);
    }
}
 
session_start();
 
print_r($files_expire);
echo 'Supprimé : '.(($unlink === TRUE) ? 'Oui' : 'Non').'<br />';

Du code vite fait bien bien sûr.

Le but de ce code est de savoir si le fichier de session est expiré, et si tel est le cas : le supprime

Et bien $unlink retourne bel et bien "Oui", (il est bien présent dans $files_expire).
Mais ce qui est délirant, c'est que le fichier est toujours là, même identifiant.

Mais encore encore plus fort, car, que cela ne tienne : je le supprime moi même (corbeille vidée aussi).
Et bien une fois actualisé la page : Le fichier de session est recréé, avec même identifiant.

Mais qu'est ce que c'est qu'ce biiiiiinds

Ceci dit, et si je regarde du coté de mon projet, donc en mettant aussi 10 secondes, et bien au bout on est bien déconnecté, une ré-identification est nécessaire, de même qu'on perd toute les données en sessions.
Malgré tout, je remarque que l'Identifiant de la session reste le même.
C'est dingue ça quand même.

Finalement, dans cet essai le fichier serait bien supprimé, mais recréé dans la foulée.
Mais est ce normal que Php conserve le même identifiant ?

Franchement, je ne comprends plus rien.
Ma tête à coupée que Php changeait d'ID une fois expirée, mais surtout après suppression du fichier.
Là, si quelqu'un a une vrai explication sur cet essai/phénomène, je preneur à 200%.

Mias j'ai remarqué un autre phénomène tout aussi inexplicable.

Mais pour le suspense, je l'évoquerais après.

En faite c'est pour ne pas créer de confusion.

@zeflex
Désolé de tout ce remou-ménage, mais si des explications sont données, on fera un point la dessus.