Heu, oui mais si au contraire tu diminue le temps de session, ca va pas le faire.
Moi je me suis mis un
define('_RENOUVELLE_ALEA', 12 * 3600 / 20); // il va être * 20 dans inc/session
pour avoir des sessions de 12h, bilan il va me les killer au bout de deux heures.
Je crois que ca nous ramene au message de fil qui disait des trucs compliqués à ce sujet, mais dont j'avais retenu qu'il manquait un truc simple dans SPIP spécifiquement pour gérer les durées de session.
BoOz
ben le probleme c'est qu'actuellement y a une partie du code ou le delai est en define, et une partie ou il est en dur
c'est ça qui va pas.
Heu, oui mais si au contraire tu diminue le temps de session, ca va pas le faire.
Moi je me suis mis un
define('_RENOUVELLE_ALEA', 12 * 3600 / 20); // il va être * 20 dans inc/session
pour avoir des sessions de 12h, bilan il va me les killer au bout de deux heures.
Non, c'est le cookie qui dure 12h
Mais la session elle est perimee au bout de _RENOUVELLE_ALEA dans tous les cas. (36 minutes dans ton cas)
Au contraire, avec ce define, il refaisait une nouvelle session (donc un fichier) toutes les 36mn, mais il nettoyait que toutes les 48h,
donc quand il y avait 80 fichiers de session périmés pour chaque auteur....
Alors que maintenant il purgera les sessions perimées toutes les 2h à peu près.
Je crois que ca nous ramene au message de fil qui disait des trucs compliqués à ce sujet, mais dont j'avais retenu qu'il manquait un truc simple dans SPIP spécifiquement pour gérer les durées de session.
Peut être oui, mais en l'occurence j'ai bien corrigé un bug 
Cédric
message de fil qui disait des trucs compliqués
Je dis juste qu'il faut ajouter dans la session un champ fin_session,
et la tuer quand elle dépasse cette valeur. Du coup on aura des
sessions dont la durée sera précisément celle qu'on a définie. En
sachant qu'en plus on perd sa session si on ne passe pas sur le site
durant tout un alea.
-- Fil
message de fil qui disait des trucs compliqués
Je dis juste qu'il faut ajouter dans la session un champ fin_session,
et la tuer quand elle dépasse cette valeur. Du coup on aura des
sessions dont la durée sera précisément celle qu'on a définie. En
sachant qu'en plus on perd sa session si on ne passe pas sur le site
durant tout un alea.
Avec du code c'est beaucoup plus simple :
http://core.spip.org/trac/spip/changeset/16585
seul souci j'ai expérimenté une nouvelle méthode de commit et j'ai
perdu le log... que voici :
{{{ _AGE_SESSION_MAX }}} permet de fixer precisement la duree maximum
d'une session ; il s'emploie dans mes_options.php comme suit
// age maximum d'une session (en secondes)
// pour ne pas avoir de deconnexion intempestive,
// le renouvellement d'alea doit etre largement
// superieur a cette valeur
define('_AGE_SESSION_MAX', 10);
tant que la valeur n'est pas définie le patch se contente d'inscrire
la date de debut de la session dans la session elle-même, donc aucune
conséquence sur le fonctionnement de SPIP. A mon avis il n'y a aucun
danger à reporter en stable. MAIS il y a peut-être plus smart à faire.
-- Fil
Ça ne réponds qu'à la moitié du besoin :
- ça permet de raccourcir les sessions sans raccourcir l'aléa
Mais si je veux a contrario avoir des sessions longues de plusieurs jours, sans pour autant rallonger l'alea, ça n'est pas possible du coup.
Si la duree de la session ne repose plus sur l'alea, pourquoi faudrait-il faire dépendre le nom du fichier/cookie de session de l'alea.
Le nom peut être independant de l'alea, et reattribue par avec uniqid quand on redonne une nouvelle session a son expiration.
Cela dit, je ne vois aucune urgence à intégrer ça dans la branche stable sauf à lui introduire des bugs.
Donc c'est à travailler sur la branche dev, ce qui permettra en sus de detecter les éventuels bugs d'ici une release de cette branche.
Cédric
- ça permet de raccourcir les sessions sans raccourcir l'aléa
oui
Mais si je veux a contrario avoir des sessions longues de plusieurs jours, sans pour autant rallonger l'alea, ça n'est pas possible du coup.
En effet il faudra rallonger l'alea pour qu'il soit supérieur à la
durée max de session. C'est logique, et ça s'explique : dans un cas,
il s'agit de régler la session de l'utilisateur, dans l'autre il
s'agit d'une configuration de sécurité interne au site.
Si la duree de la session ne repose plus sur l'alea, pourquoi faudrait-il faire dépendre le nom du fichier/cookie de session de l'alea.
L'aléa est surtout là afin d'éviter de se faire voler des cookies de
session ou des fichiers (ls tmp/session/ ) et de pouvoir en déduire
une manière d'entrer dans le site n'importe quand. Comme il
définissait en quelque sorte une durée max de session, ça donnait ce
qu'on a, mais en aucun cas l'aléa n'était conçu dans le but de définir
la durée de session.
Cela dit, je ne vois aucune urgence à intégrer ça dans la branche stable sauf à lui introduire des bugs.
Je ne crois pas qu'il y ait possibilité de bug là, puisque le code ne
s'exécute que si un define est présent.
Mais j'aimerais qu'on discute plutôt des specs, car dès lors que ça
commencera à être utilisé on sera embêté si on n'y a pas réfléchi.
Donc c'est à travailler sur la branche dev, ce qui permettra en sus de detecter les éventuels bugs d'ici une release de cette branche.
comme tu veux
-- Fil
Mais si je veux a contrario avoir des sessions longues de plusieurs jours, sans pour autant rallonger l'alea, ça n'est pas possible du coup.
En effet il faudra rallonger l'alea pour qu'il soit supérieur à la
durée max de session. C'est logique, et ça s'explique : dans un cas,
il s'agit de régler la session de l'utilisateur, dans l'autre il
s'agit d'une configuration de sécurité interne au site.
Ah j'ajoute quand même un truc : actuellement si on s'aperçoit que le
fichier de session est vieux et risque de se faire zapper par le
changement d'aléa, on le renomme. Il faut donc laisser courir toute
une période assez longue pour perdre sa session.
-- Fil