Durée de vie d'une session [Résolu]

[dbass]

Bonjour à tous.

Je me casse la tête sur un problème concernant la durée de vie de mes sessions. Mon but est de passer des 24 minutes fixées par défaut par session.gc_maxlifetime à 4 heures.

Le site étant hébergé en mutualisé, je n'ai pas la possibilité de changer php.ini.

1ère tentative :

Code :

1
2
3
4
5
6
7
 
ini_set('session.save_path',$_SERVER['DOCUMENT_ROOT'] . '/../repdestockage');
ini_set('session.cache_expire',4 * 60);
ini_set('session.cache_limiter','none');
ini_set('session.cookie_lifetime',4 * 3600);
ini_set('session.gc_maxlifetime',4 * 3600);
session_start();

Alors c'est super, les paramètres sont à priori pris en compte (test avec ini_get) MAIS quand, en local, je vois effectivement apparaître mes jolis fichiers de sessions dans le rep choisi, sur le serveur mutualisé le répertoire reste vide, que ce répertoire soit placé dans le rep public du site ou dans un niveau inférieur (avec 777 comme droits sur le rep). Et, évidemment, mes variables de sessions sont écrasées au bout de 24 minutes...

2ème tentative :

Code :

1
2
3
4
5
 
// inclusion des fonctions perso de gestion des sessions
ini_set('session.save_handler','user');
session_set_save_handler('_open','_close','_read','_write','_destroy','_gc');
session_start();

La voici, la voilà, la gestion personnalisée des sessions (j'ai essayé avec ou sans une classe) qui se sert d'une base mysql.

En local, aucun problème, sur le serveur mutualisé, la directive session_set_save_handler me renvoit false...

Je pense que j'ai essayé les deux alternatives possibles pour contourner le fait de ne pas pouvoir toucher à php.ini... Le plus énervant est que cela marche en local et pas sur le serveur mutualisé. Il pourrait sans doute s'agir de sa version de PHP... Je vous donne les infos de ce serveur, si quelqu'un a une suggestion, je suis preneur !

Merci à tous,
dbass.

Code :

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
 
PHP Version 4.2.2 
 
System Linux sylvester.devel.redhat.com 2.4.20-2.41smp #1 SMP Sun Feb 9 09:29:47 EST 2003 i686 athlon i386 GNU/Linux 
Session Support enabled 
 
Directive Local Value Master Value 
session.auto_start
 On On 
session.cache_expire
 240 180 
session.cache_limiter
 none nocache 
session.cookie_domain
 no value no value 
session.cookie_lifetime
 14400 0 
session.cookie_path
 / / 
session.cookie_secure
 Off Off 
session.entropy_file
 no value no value 
session.entropy_length
 0 0 
session.gc_maxlifetime
 14400 1440 
session.gc_probability
 1 1 
session.name
 PHPSESSID PHPSESSID 
session.referer_check
 no value no value 
session.save_handler
 files files 
session.save_path
 /var/www/html/web/rep/www/toto/../toto_data/tmp /tmp 
session.serialize_handler
 php php 
session.use_cookies
 On On 
session.use_trans_sid
 1 1

[dbass]

Personne ?

Je comprends vraiment pas le problème... Pour l'instant, j'ai fait une rustine avec un js qui reload la page avant les 24 minutes fatidiques mais c'est bourrin...

[AurelBUD]

Moi je declare la date de dernier acces dans une variable de session et à chaque foisn que j'accede a ma page je remet à jour cette variable.
Si elle n'as pas été mise à jour pdt un temp x défini, la varible de session est detruite.

Initialisation de la variable :

Code :

$_SESSION['last_access'] = time();

Test du temps d inactivité :

Code :

1
2
3
4
5
$timeout = 1440; //24 minutes
if ( time()-$_SESSION['last_access'] > $timeout )
{
	session_destroy();
}

[dbass]

Bien sûr, le problème est que si le garbage collector passe avant le timeout que tu définis, tes variables de sessions sont effacées... càd pour tuot timeout supérieur à session.gc_maxlife... paramètre que j'ai modifié avec ini_set pour contourner ce problème mais il n'est manifestement pas pris en compte sur le serveur mutualisé.

Et pourquoi le session.save_path n'est-il pas non plus opérant ? Je ne vois pas ce que je rate... Y a t-il des paramètres Apache ou PHP qui empêchent ou court-circuitent les ini_set ? Je sais que le gros problème est que déjà les ini_set ne sont valable que pendant l'exécution du script donc je pensais que c'est pour cela que ini_set('session.gc_maxlifetime','grosse valeur') était ignoré mais non, en l'appelant bien avant session_start(), cela marche très bien en local. Mais surtout parce qu'en local mon iniset('session.save_path','mon_rep') est bien opérant alors qu'en distant, niet ! Du coup les fichiers de sessions sont je pense encore stocké dans le rep par défaut qui se prend le garbage collector aux intervalles fixés pour ce rep à savoir ces fameuses 24 minutes...

Pourquoi est-ce que ma demande de changement de rep pour sauver les 'files' de sessions n'est pas prise en compte sur ce serveur mutualisé ???

grr

[AurelBUD]

Pourquoi tu ne pauses pas la question à l'administrateur du serveur mutualisé ???

[FMaz]

J'ai eu le même problème, et j'ai finalement programmé mon propre système de session...

Si tu trouve une solution, je serais ravi de l'apprendre.

Et si jamais tu pense créer un compteur de visiteurs en ligne sur ton site, dit toi que pour ce faire, ca créer un 2ieme système de session, donc aussi bien en utiliser qu'un seul ;p

[dbass]

J'ai essayé une gestion de session mysql mais le php du mutualisé me renvoie false quand je veux debrayer en 'user' la gestion des sessions. Après, je pourrais effectivement recréer entièrement le méchanisme des sessions, mais qand même... Ca devrait marcher !

Bref, pour l'instant, je contourne le problème avec un javascript qui reload le fichier toutes les 20 minutes.

[macbook]

Essayes avec session_regenerate_id ( true ) ; ???

En passant comme paramètre true, tu effaces l'ancien fichier de session pour en créer un nouveau, c'est un peu lourd mais cela pourrait tromper l'ennemi.

[dbass]

bonne idée je vais tester !

merci !