[spip-dev] Durée de la session (variable $auth['cookie'] fantome et multiplications à gogo de la valeur par défaut)

BoOz · Août 2, 2010, 12:27

Hello,

Je cherche à maitriser la durée de la session visiteurs dans SPIP.

Je vois qu'il y a une variable dans inc/utils qui à l'air de servir à ca dans inc/utils.php :

// Duree de validite de l'alea pour les cookies et ce qui s'ensuit.
define('_RENOUVELLE_ALEA', 12 * 3600);

Par exemple dans ce commentaire de /prive/formulaires/login.php on lit ca :

// Construire l'environnement du squelette
// Ne pas proposer de "rester connecte quelques jours"
// si la duree de l'alea est inferieure a 12 h (valeur par defaut)

Sauf que si on creuse un peu, on voit qu'en fait le calcul de la durée est dasn inc/session :

$duree = _RENOUVELLE_ALEA *
      (!isset($auth['cookie'])
        ? 20 : (is_numeric($auth['cookie'])
        ? $auth['cookie'] : 2));

Donc non pas la valeur par defaut, mais celle ci fois 20 (10 jours quoi) et encore ca c'est dans le cas ou la variable $auth['cookie'] n'est pas définie avec une valeur numérique, auquelle cas cette valeur est la durée, et si $auth['cookie'] n'est pas numerique alors la c'est 2 (un jour quoi).

Quelle est la bonne méthode pour fixer la valeur de la session ? Diviser la valeur qu'on veut par 20 et la mettre en _RENOUVELLE_ALEA ? Ou bien tâcher de surcharger $auth['cookie'] ?

Sachant que d'après mes recherches $auth['cookie'] n'est définie nulle part et que donc c'est toujours 20*_RENOUVELLE_ALEA qui est retenue.

BoOz

George · Août 2, 2010, 1:38

Quoting BoOz <booz@rezo.net>:

Hello,

Je cherche à maitriser la durée de la session visiteurs dans SPIP.

Je vois qu'il y a une variable dans inc/utils qui à l'air de servir à ca dans inc/utils.php :

// Duree de validite de l'alea pour les cookies et ce qui s'ensuit.
  define('_RENOUVELLE_ALEA', 12 * 3600);

Par exemple dans ce commentaire de /prive/formulaires/login.php on lit ca :

// Construire l'environnement du squelette
  // Ne pas proposer de "rester connecte quelques jours"
  // si la duree de l'alea est inferieure a 12 h (valeur par defaut)

Sauf que si on creuse un peu, on voit qu'en fait le calcul de la durée est dasn inc/session :

$duree = _RENOUVELLE_ALEA *
      (!isset($auth['cookie'])
        ? 20 : (is_numeric($auth['cookie'])
        ? $auth['cookie'] : 2));

Donc non pas la valeur par defaut, mais celle ci fois 20 (10 jours quoi) et encore ca c'est dans le cas ou la variable $auth['cookie'] n'est pas définie avec une valeur numérique, auquelle cas cette valeur est la durée, et si $auth['cookie'] n'est pas numerique alors la c'est 2 (un jour quoi).

Quelle est la bonne méthode pour fixer la valeur de la session ? Diviser la valeur qu'on veut par 20 et la mettre en _RENOUVELLE_ALEA ? Ou bien tâcher de surcharger $auth['cookie'] ?

Sachant que d'après mes recherches $auth['cookie'] n'est définie nulle part et que donc c'est toujours 20*_RENOUVELLE_ALEA qui est retenue.

BoOz

Hi

Je ne me rappelle plus quel calcul j'ai fait mais j'ai fixe des sessions de 3600 secondes avec:

define('_RENOUVELLE_ALEA', 180);

dans mes_options.php

George

BoOz · Août 2, 2010, 2:47

george@middleeastwatch.net wrote:

Je ne me rappelle plus quel calcul j'ai fait mais j'ai fixe des sessions de 3600 secondes avec:
define('_RENOUVELLE_ALEA', 180); dans mes_options.php

Oui, cela revient à diviser la valeur souhaitée par 20...

En fait en regardant de plus près avec le concours des gens de l'irc, et notamment denib, il semblerait que inc/session.php soit bugguée (variable $auth non définie) et à l'envers, avec les gens qui souhaitent être loggué longtemps qui sont logués pas longtemps et les autres longtemps.

Le code devrait probablement être :

Non pas :

$duree = _RENOUVELLE_ALEA *
      (!isset($auth['cookie'])
        ? 20 : (is_numeric($auth['cookie'])
        ? $auth['cookie'] : 2));

Mais :

$duree = _RENOUVELLE_ALEA *
      (!isset($auteur['cookie'])
        ? 2 : (is_numeric($auteur['cookie'])
        ? $auteur['cookie'] : 20));

Enfin, on peut s'interroger sur la pertinance de fixer ... si c'est pour le multiplier ensuite. Autant le fixer tout de suite à la bonne valeur, ce qui évitera les calculs ahurrissant aux webmestres pour fixer la durée de la session.

Le code serait donc finalement :

$duree = _RENOUVELLE_ALEA *
      (!isset($auteur['cookie'])
        ? 1 : (is_numeric($auteur['cookie'])
        ? $auteur['cookie'] : 20));

Avec dans inc/utils

// Duree de validite de l'alea pour les cookies et ce qui s'ensuit.
define('_RENOUVELLE_ALEA', 24 * 3600);

Enfin, je crois sans en être certain que la case à cocher dans le form de login qui permet de fixer une valeur texte à $auteur['cookie'] et être loguer pendant 20*_RENOUVELLE_ALEA ne passe pas dans auth_loguer().

Bilan de l'enquete, à l'heure actuelle, toutes les sessions font 10*_RENOUVELLE_ALEA, le reste ne marche pas.

BoOz

esj · Août 2, 2010, 4:03

Yep, cf
http://trac.rezo.net/trac/spip/changeset/15897
qui rétablit l'intention de SPIP < 2.0 mais je n'ai jamais trop regardé ce que ça voulait faire au juste.

En revanche, ceci me fait rendre compte que le répertoire auth a maintenant un fichier sha256.inc.php qui ne devrait pas y être:
ce répertoire doit contenir que de des fichiers proposant une méthode d'authentification,
les fichiers qu'ils incluent doivent être dans inc/

Committo,Ergo:Sum

fil · Octobre 14, 2010, 11:50

Je crois que ça mérite une petite explication

D'abord, attention à ne pas mélanger la durée max du cookie de session
côté client avec la durée max de la session côté serveur.

Pour expliciter la différence : supposons qu'on souhaite avoir une
durée de session de 12h. On ne peut pas se contenter de poser un
cookie de 12h au client, car s'il est méchant et qu'il note sur un
petit papier le cookie de session, il peut le remettre ensuite dans
son navigateur après l'expiration. Il faut donc aussi que la session,
si elle est active trop longtemps, soit invalidée côté serveur.

Pour gérer ce genre de situations SPIP dispose d'un "aléa" interne,
qu'il renouvelle toutes les 12 heures :
define('_RENOUVELLE_ALEA', 12 * 3600);

Toutes les douze heures donc, en cron, l'alea est remplacé par une
nouvelle valeur aléatoire, et la précédente valeur est stockée dans
alea_ancien.

Quand un client se présente avec un cookie disant "j'ai la session
1_123456879789", SPIP cherche dans tmp/sessions/ le fichier
1_acbdef1245453232.php ; où acbdef1245453232 = md5(alea +
123456879789).

De cette façon quand l'alea change, un vieux cookie de session n'a
plus d'usage possible.

Mais ça pose un problème si on vient de se loger quand le cron fait
tourner l'alea ; il faudrait donc alors se reloger... c'est pour
éviter ça qu'on regarde dans un second temps si le fichier
1_64231654263541625431623.php existe, où 64231654263541625431623 =
md5(alea_ancien + 123456879789). Ca permet à la session de vivre
au-delà d'une rotation de l'alea.

Ce qui se passe avec le login de SPIP, quand on coche la case "[x]
rester connecté", c'est que le cookie de session dure 20 * 12 h. Ce
qui implique que, si l'on navigue sur le site au moins une fois par
période de douze heures, on peut rester connecté 10 jours sans avoir à
se reloger. En revanche si on n'a pas coché cette case, le cookie est
posé pour "seulement" 24 h quoi qu'il arrive. L'idée c'est de
minimiser le scénario où l'on va dans un cyber café, on se loge, on
oublie ensuite de se déloger, le risque que quelqu'un d'autre passe
ensuite et chope notre connexion. Dans tous les cas si on est inactif
sur le site durant au moins 12 heures, le cookie de session ne sert
plus à rien.

* * *

A la réflexion je me dis que ça a un peu vieilli. Il serait sans doute
plus simple de noter la date de fin de session dans le fichier
temp/sessions/1_xxxxxxx , et si la session dépasse cette date, de
savoir dans quel cas on la renouvelle automatiquement (j'ai coché la
case "rester connecté" et la session n'a pas plus de x heures), et
dans quel cas on la supprime. On pourrait alors passer une durée de
session (optionnelle) à la fonction session_set().

Mais ce n'est pas à ça que sert RENOUVELLE_ALEA.

-- Fil