Table des sessions qui gonfle

[pmleconte]

Pour revenir sur le problème initial, il n'est pas normal que des bots et autres indésirables essaient d'accéder à com_user.

J'ai un composant CG Secure https://extensions.joomla.org/extens...ity/cg-secure/ qui, entre autres fonctions, bloque l'accès à com_admin et com_user aux pays non autorisés.

Cela devrait résoudre ton problème d'accès non souhaités à com_user.

Pascal

[pmleconte]

Petite réflexion complémentaire : ton adresse logout ne serait-elle pas dans ton site map ?

Pascal

[RobertG]

Merci Pascal, je vais étudier ton composant.

Pour le moment, le vidage se fait régulièrement par des visites "normales" je pense, et je ne comprends toujours pas pourquoi ces adresses vers un lien de déconnexion n'ont pas le même rôle de déclenchement de la purge qu'un accès normal.
Les adresses semblent pourtant correctes. Les adresses Yandex et Facebook pourraient-elles ne pas être celles d'origine mais de fausses infos ?

57.141.0.14 jyjou.com - [30/Nov/2024:23:58:22 +0100] "GET /index.php?option=com_users&task=user.logout&319bad a453ab7d73c2f42339b6debb21=1&return=aHR0cHM6Ly9qeW pvdS5jb20v&Itemid=789 HTTP/1.1" 303 - "-" "meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)"

Et oui, l'adresse est dans le sitemap. J'ai supprimé l'indexation du lien, je ne sais pas si je pourrai le faire pour son insertion dans le plan.

PS : bien supprimé du plan, c'était un lien de déconnexion au simple clic, sans confirmation. Attendons la suite.

[pmleconte]

Quel type d'accès pour ton menu logout ? registered ?
si oui, il ne doit pas être dans le sitemap.
si non, pas normal...

[RobertG]

En effet, il était en public, de même que tous les autres liens de ce menu. J'ai tout passé en enregistré, en attendant de les passer peut-être en "special" puisque c'est pour la gestion frontale.

Ce qui est ennuyeux est que les logs OVH ne sont accessibles que depuis le Manager (et il est à double identification), et je ne me souviens pas si on a ceux du jour actuel ou seulement des jours précédents.

Je viens d'accéder aux logs web en temps réel et rien ne change :
57.141.0.10 jyjou.com - [02/Dec/2024:17:15:17 +0100] "GET /index.php?option=com_users&task=user.logout&2e65d8 fe9021d34a82f654c3637ea56d=1&return=aHR0cHM6Ly9qeW pvdS5jb20v&Itemid=789 HTTP/1.1" 303 - "-" "meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)"

[RobertG]

Faudrait-il carrément bloquer toutes les IP 57.141.0.* ?

Avec un deny from 57.141.0 ça bloque bien le crawler Facebook, mais si d'autres en IP 57.141.0xx accèdent au site, ils vont être rejetés, non ?

[lefabdu51]

ton erreur 303 indique une redirection vers une page d avancement de la requete ou autre
Le code de statut de réponse de redirection 303 See Other, généralement renvoyé comme résultat d'une opération PUT ou POST, indique que la redirection ne fait pas le lien vers la ressource nouvellement téléversée mais vers une autre page (par exemple une page de confirmation ou qui affiche l'avancement du téléversement). La méthode utilisée pour afficher la page redirigée est toujours GET.

Qu est ce qui a l'id 789 ? un module ? un article ?

[RobertG]

Oui, comme je l'ai dit un peu plus haut, 789 est l'ID du lien lui-même, et le lien en question est de type déconnexion, qui renvoie automatiquement à l'accueil, sans passer par la confirmation de déconnexion.

La question que je me pose est de savoir si deny from 57.141.0 doit se terminer par un point pour ne pas interdire aussi les 57.141.0xx.xxx