Bonjour,
Par défaut sur Debian, les sessions PHP sont purgées toutes les 24 minutes par un script cron. Ce script ne tient pas compte d’un éventuel maxlifetime pour les sessions définis dans un vhost Apache.
Y a-t-il un moyen (propre et sécurisé = pas de risque d’hijacking) de définir un maxlifetime pour les sessions différent pour un vhost ?
Merci
Salut,
[quote=“archimedio”]Bonjour,
Par défaut sur Debian, les sessions PHP sont purgées toutes les 24 minutes par un script cron. Ce script ne tient pas compte d’un éventuel maxlifetime pour les sessions définis dans un vhost Apache.
Y a-t-il un moyen (propre et sécurisé = pas de risque d’hijacking) de définir un maxlifetime pour les sessions différent pour un vhost ?
Merci[/quote]
[code]cat /etc/cron.d/php5
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null ; -delete[/code]
As tu essayé ce qui suit ?
En créant un fichier php.ini par vhost.
En modifiant la valeur “max=xxx” des sessions /usr/lib/php5/maxlifetime ?
Je n’ai pas essayé ta solution, mais dans la doc PHP, il y a ceci :
[quote]Note:
Si des scripts différents ont des valeurs différentes de session.gc_maxlifetime mais partagent le même endroit pour y stocker les données de session, alors, le script dont la valeur est la plus petite effacera la donnée. Dans ce cas, utilisez cette directive conjointement avec session.save_path. [/quote]
Je pense donc que ça ne marchera pas. La seule solution semble être de créer un dossier de sessions séparé pour ce vhost. Mais dans ce cas, il faut mettre en place manuellement un garbage collector efficace…
Salut,
[quote=“archimedio”]Je n’ai pas essayé ta solution, mais dans la doc PHP, il y a ceci :
[quote]Note:
Si des scripts différents ont des valeurs différentes de session.gc_maxlifetime mais partagent le même endroit pour y stocker les données de session, alors, le script dont la valeur est la plus petite effacera la donnée. Dans ce cas, utilisez cette directive conjointement avec session.save_path. [/quote]
Je pense donc que ça ne marchera pas. La seule solution semble être de créer un dossier de sessions séparé pour ce vhost. Mais dans ce cas, il faut mettre en place manuellement un garbage collector efficace…[/quote]
Navré mais, je ne pourrai te venir en aide au-delà, fait nous part de la suite (stp). 
et pourquoi pas reconf pour chaque vhost ?
<vhirtualhost ...>
....
php_admin_value session.save_path "/ton/dossier/receptacle/des/sessions/du/vhost/"
php_admin_value session.max_lifetime "ton_temps"
...
</virtualhost>
[quote=“Mitsu”]et pourquoi pas reconf pour chaque vhost ?
<vhirtualhost ...>
....
php_admin_value session.save_path "/ton/dossier/receptacle/des/sessions/du/vhost/"
php_admin_value session.max_lifetime "ton_temps"
...
</virtualhost>[/quote]
C’est la première solution que j’envisageais. Mais dans ce cas, il faut bien paramétrer le dossiers de stockage des sessions (droits d’accès, facile) mais surtout ne faut-il pas mettre en place un GC pour ce dossier ? PHP ne va pas le nettoyer automatiquement, si ? Et si ce n’est pas le cas, comment mettre en place le GC ?
up
crées un groupe spécifique à ça
change le folder en chmod 770
change l’owner/groupe en ton_user:le_groupe
ajoute ton user à ce groupe
ajoute l’user web à ce groupe (www-data si inchangé dans les conf apache)
de là, ça devrait aller et rester secure un minium si je ne m’abuse tout en laissant à l’user la main sur les sessions si nécessaire
à défaut, cales direct tous les droits sur l’user www-data et chmod en 700
Voici la solution que j’ai finalement adoptée. Si vous avez des avis dessus (c’est ok ou au contraire, c’est pas top), merci de m’en faire part 
J’ai créé un répertoire “sessions” à la racine de mon shaarli. J’en ai interdit l’accès via Apache et sa directive deny from all.
J’ai ensuite ajouté une directive php_value dans mon vhost pour changer le save_path des sessions vers le répertoire précédent.
Ce répertoire est maintenant hors de portée du script de GC de PHP. J’ai donc créé une deuxième tâche cron comme ceci :
[code]# /etc/cron.d/php5: crontab fragment for php5
09,39 * * * * root find /home/phyks/www/links/sessions/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +2592000 ! -execdir fuser -s {} 2>/dev/null ; -delete[/code]
J’ai était confronté au même problème cette semaine, sauf que c’était pour le répertoire dans un vhost.
Ce poste m’a bien aidé, je vous indique ici ce que moi j’ai fait , si jamais ca peut aider le suivant :
<VirtualHost *:443>
ServerName monsite.mondomaine.com
DocumentRoot /home/www/monsite
SSLEngine on
SSLCertificateFile /etc/ssl/certs/*.crt
SSLCertificateChainFile /etc/ssl/certs/*.crt
SSLCertificateKeyFile /etc/ssl/private/*.key
LogLevel warn
ErrorLog /var/log/apache2/error-monsiteHTTPS.log
<Location /repertoire1>
php_admin_value session.save_path "/home/www/session/"
php_value session.gc_maxlifetime 86400
</Location>Ensuite, j’ai éditer le fichier cron (/etc/cron.d/php5 )pour faire passer le GB :
##GB pour Repertoire Session
0 */1 * * * find /home/www/session/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +1440 ! -execdir fuser -s {} 2>/dev/null \; -deleteAlors pour les petits précisisions :
gc_maxlifetime = Secondes
cmin = Minutes (oui je sais lui ca parait évident :p)
Mes valeurs correspondent à 24H, c’est pour des sessions sur des pages qui se chargent sur des écrans sur les différents sites (bref l’utilité osef non ? 
).
Voila, si jamais ca peut aider mon prochain . En tout cas merci pour les infos ici, ca m’a grandement facilité la tâche!!
Salut,
Très sympa ce retour Kristy et nul doute sur son utilité futur.