Invalid sesskey : Clef de session incorrecte ?

Re: Invalid sesskey : Clef de session incorrecte ?

par Séverin Terrier,
Nombre de réponses : 1
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Bonjour,

Suite à une recherche sur les termes indiqués en erreur, je suis tombé sur MDL-47680 (fermé faute de précisions) et MDL-48960 (qui vient d'être corrigé très récemment).

Il semblerait que c'est effectivement lié aux accès anonymes, sans doute par les robots indexeurs.

Cela vaut le coup de passer à la dernière version 2.7.5+ pour voir si cela résout le problème clin d’œil

Séverin

En réponse à Séverin Terrier

Re: Invalid sesskey : Clef de session incorrecte ?

par Nicolas Mouillet,

Bonjour,

Je n'avais pas vu le bug MDL-48960 lors de mes recherches. Le sujet est un peu différent car l'erreur vient là du lien en pied de page pour passer du thème mobile au thème classique, mais dans les commentaires l'un des développeurs évoque le problème que nous avons ici et il semble être de même nature.

En regardant leur solution j'ai effectivement pu comprendre un peu mieux ce qui se passe (du moins je le pense).  Les liens générés dans calendar/set.php semblent correspondre aux boutons "Cacher les événements globaux" et "Cacher les événements de cours" dans le bloc "Calendrier". Ces liens s'affichent même aux utilisateurs non authentifiés et sont probablement suivis par des robots, c'est à ce moment que l'erreur se déclenche.

En effet, lorsqu'un humain non connecté clique sur ces liens il n'y a pas d'erreur car voici ce qui apparaît dans mon log des sessions:

 1424952594   ELG   6k1FjrgquF   6k1FjrgquF   guest 1

Le compte est alors "guest 1" et la session correspond, je ne sais pas pourquoi le compte n'est pas guest 1 pour les robots mais je sais qu'il est possible que les robots aient à chaque requête une nouvelle session, comme lorsque l'on ferme son navigateur puis qu'on le ré ouvre... (EDIT: c'est tout simplement parce que les robots ne gèrent pas les cookies, hors ce sont ces cookies qui permettent de lier un utilisateur avec sa session sur le serveur et donc de savoir qui il est! Pas de cookie > pas de correspondance de session > erreur) 

En définitive j'ai comparé les liens du calendrier avec ceux d'une plateforme de test en version 2.8.3+, on peut effectivement voir que le problème semble corrigé. Voici un lien sur la version de production:

<a href=".../calendar/set.php?return=L2NvdXJzZS92aWV3LnBocD9pZD0xNDIz&amp;sesskey=6k1FjrgquF&amp;var=showglobal"><span class="calendar_event_global">...</a>

Et voici son équivalent sur la version de test 2.8.3:

<a href=".../calendar/set.php?return=L2NhbGVuZGFyL3ZpZXcucGhwP3ZpZXc9bW9udGgmdGltZT0xNDI0OTQ4ODYxJmNvdXJzZT0x&amp;sesskey=Zspv53A6xD&amp;var=showglobal" rel="nofollow">...</a>

Le rel="nofollow" semble suffire à empêcher les robots de suivre le lien, le problème a donc été résolu. Je reste surpris que des robots fassent tant de requêtes sur nos plateformes...

Merci pour votre aide et votre temps.

Bien à vous



Moyenne des évaluations Utile (1)