[RÉGLÉ] Table des sessions qui gonfle

[RobertG]

Bonjour,

Hier j'ai dû intervenir sur le site d'un client dont la table des sessions avait fait exploser le quota de la base de 512 Mo alors que les autres tables ne représentent qu'environ 30 Mo.
L'hébergeur avait bloqué la base, et après nettoyage et recalcul de ce quota, la base a été débloquée et le site est redevenu fonctionnel.
La durée des sessions était de 60 minutes et j'ai rapidement retrouvé un nombre de lignes dans cette table dépassant 7000. J'ai modifié le rythme de purge de 24h à 1h, ce qui a immédiatement réduit à un peu plus de 2000 le nombre d'enregistrements.
Ce matin, 17.000 et quelques lignes. Je réduis à 20 minutes le temps de session et là encore une forte baisse intervient. Mais quelques instants plus tard, retour à un nombre de lignes à plus de 15.000 !
L'enregistrement des erreurs 404 montre qu'il n'y a pas d'attaque à proprement parler : en quelques instants, si le nombre de session a bien augmenté, je n'ai qu'une erreur 404 sur une tentative d'accès à un fichier WP.

La réduction du temps de session et du délai de purge semblent protéger pour le moment du dépassement de quota (table session de l'ordre de 17 Mo), que faut-il penser de ces accès ?

Je n'ai pour le moment pas accès aux logs.

Merci de vos conseils.

[RobertG]

J'ai pu avoir accès aux logs de connexion pour la journée d'hier, et j'ai 29463 adresses de déconnexion de ce type pour Yandex (25303 lignes en tout pour ce robot) et Facebook (33628 lignes).

/index.php?option=com_users&task=user.logout&566dd5 80ae25ce21b0523cea33fab7c1=1&return=aHR0cHM6Ly9qeW pvdS5jb20v&Itemid=789

ou

/Se-deconnecter.html?f2d9881e051fc27afd7d5a3778b4db2f= 1&return=aHR0cHM6Ly9qeWpvdS5jb20v

63463 lignes de logs web OVH, 58567 codes 303 !

Pourquoi ces adresses de déconnexion avec un identifiant et une adresse de retour, sachant que les seuls membres du site sont son propriétaire et moi ?
Par exemple

/index.php?option=com_users&task=user.logout&566dd5 80ae25ce21b0523cea33fab7c1=1&return=aHR0cHM6Ly9qeW pvdS5jb20v&Itemid=789

Il y a bien un lien de menu "Se déconnecter", mais pourquoi les robots utilisent-ils de telles adresses ?

[cavo789]

Hello

Du spam.. Regarde la variable return. Il y a du code base64. Si tu y prêtes attention et que tu la décode, tu trouveras une URL. Je suppose que ce n'est pas ton site.

Si tu veux un décodeur en ligne, j'en ai créé un pour le fun il y a quelques années : https://base64.avonture.be/

[RobertG]

Merci Christophe, mais les adresses correspondantes sont de type

htt ps://developers.facebook.com/docs/sharing/webmasters/crawler

et

htt p://yandex.com/bots

[cavo789]

Celle de ton dernier copié collé est jy jo u... Je n'ai pas ouvert ce site.

Est-ce que l'intérêt est de forcer ton site à visiter le site distant ? Il y a forcément un intérêt à ces "attaques", des requêtes bidons lancées vers ton site.

[RobertG]

Jyjou suivi de .com est le site concerné. Il s'agit du site de mon client, un clown.
L'ID 789 est celle du lien de déconnexion.

[RobertG]

Bonjour,

Il y a quelques minutes, la table comportait 28183 lignes.
J'ai voulu voir dans l'administration à quelle heure la tâche allait se déclencher, et ô surprise, elle venait juste de se lancer, à l'heure précise de mon identification.
Le rafraichissement de la page dans phpMyAdmin a vu alors ce nombre passer à 844, puis en 20 minutes à 2380... soit environ 1500 nouvelles, ce qui en donnerai 4500 à l'heure, en plus des 844 précédentes. On est loin des 28183.

Ce déclenchement de la purge au moment où je me suis connecté (ou celui où j'ai accédé à la page d'identification juste avant) m'évoque une discussion récente dont je n'ai pas retenu le titre, mais où la question était posée à propos du déclenchement des tâches par l'accès d'un visiteur sur le site et non pas automatiquement au rythme défini dans la tâche.
Est-on vraiment sûr de ce rythme fixe et indépendant des visites ? Malheureusement, la table des tâches ne conserve pas les heures de déclenchement, et celle des actions non plus. Je viens de constater que cet enregistrement des tâches était désactivé, je viens de l'ajouter dans es paramètres du journal.
D'autre part, si mon hypothèse de déclenchement par une visite est juste, comment les actions des robots Yandex et Facebook créent-ils des sessions sans pour autant forcer ce nettoyage si le délai d'une heure dans ce cas est atteint ?

[RobertG]

Bon, l'enregistrement des actions ne concerne pas leur déclenchement...
Je viens de modifier la tâche elle-même, en espérant que cette fois j'aurai des infos utiles.

[RobertG]

Bon, je confirme que la tâche ne respecte pas le rythme défini. Elle s'était lancée à 8h47 et devait donc se lancer à nouveau à 9h47 et elle ne l'a pas été.
Malgré l'accès au site dix minutes plus tard, pas de purge.
Quel paramétrage faut-il donc faire pour que ce l'horaire soit respecté ?

Et pourquoi l'heure de prochaine exécution, lorsqu'on a défini une heure de délai, passe-t-elle ici à environ 1h30 ?


En fait dès qu'on ouvre en édition cette tâche et qu'on valide, il n'y a pas purge mais report de l'heure de la future. C'est plutôt surprenant !

[lefabdu51]

salut, je serait de toi je n utiliserais pas une tache cron joomla pour cela.
Suis plutot cette procédure

https://help.ovhcloud.com/csm/fr-web-hosting-automated-tasks-cron?id=kb_article_view&sysparm_article=KB0052534

[RobertG]

Merci, mais pour vider la table des sessions par tâche perso, il faut créer un script, je ne vois pas de solution dans Joomla!, à moins qu'il y ait une adresse utilisable déjà présente dans Joomla!

En fait, la question est surtout de comprendre pourquoi ces robots accèdent aussi souvent à la page de déconnexion. Je viens de forcer un noindex-nofollow sur le lien de menu en question, on verra si ça a un impact;, mais j'ai des doutes.

[pmleconte]

Bonjour Robert,

Pour répondre à ta question du respect de horaire de déclenchement des tâches, il faut effectivement que quelqu'un visite ton site pour qu'elle se déclenche, donc, pas de respect des horaires.

On a eu une discussion sur ce sujet et j'ai résolu (involontairement) ce problème avec uptimerobots : https://forum.joomla.fr/forum/joomla...15#post2066215

Pascal

[RobertG]

Merci Pascal,

Je verrai demain matin si la table a été nettoyée pendant la nuit, avec l'envoi d'un mail à chaque purge, et si la table gonfle beaucoup ou pas.
Ce qui est étonnant est que le volume avait été considérable au point de saturer la base, plusieurs centaines de Mo en un peu moins de 48 heures, si je compte bien, puisque le rythme était alors de 24h pour les purges.

Si je comprends le rôle de uptimerobots, il suffirait d'un cron chez l'hébergeur ouvrant l'accueil du site, si l'hébergeur utilise une adresse.

Cette histoire rejoint celle d'une extension qui était un plugin de recherche de mise à jour d'extensions pour J3 et qui a été reprise en tâche planifiée : si les deux nécessitent une visite pour se déclencher, je ne vois pas très bien l'avantage de la tâche.

[pmleconte]

Pour UptimeRobot https://uptimerobot.com/, il suffit de s'enregistrer (c'est gratuit) et de déclarer son/ses sites web (sans rien installer). Ensuite, il vérifie tout seul si le site fonctionne ou pas toutes les 5 minutes (par défaut) et il envoie un mail quand un site tombe.

Pascal

[RobertG]

Merci Pascal !