Bonjour,
Sur un site en spip 1.9.2.i, plugins balise_session, accès_restreint,
couteau_suisse un onglet permet la connexion des adhérents avec :
[(#SESSION{id_auteur}|?{'',' '})<li><a href="#URL_PAGE{login_public}"
title="Identification des adhèrents">Espace
adhèrents</a></li>]
et login_public.html contient :
[(#LOGIN_PUBLIC|spip.php?page=sommaire)]
Tout ceci fonctionnait à merveille depuis bien longtemps, sauf que
depuis quelques semaines maintenant, l'appel à :
[(#LOGIN_PUBLIC|spip.php?page=sommaire)]
ne donne pas http://www.xxxx/spip.php?page=login_public
comme il se devrait,
En vidant le cache, la situation revient difficilement à la normale, et
le phénomène se reproduit après quelques accès de manière aléatoire.
J'ai vidé le tmp par ftp, remplacé la version des plugins, examiné tous
les fichiers concernés sans rien trouver d'anormal et je sèche.
Oui, argh... merci pour le lien j'ai lu tout le fil attentivement
sans solution et le pb posé semble différent.
Dans le cas que je soulève, la génération se produit à l'appel de #LOGIN_PUBLIC, suivi du filtre |spip.php?page=sommaire
de manière aléatoire !
Depuis que j'ai posté, le phénomène ne se produit plus sachant que j'ai
corrigé
la dernière génération erronée d'url à la main directement dans l'url en
supprimant un spip.php en trop.
Je poursuivrai le fil demain en cas de récidive.
A+ et merci
JPH
provenait, non pas d'un réglage SPIP, mais de lignes ajoutées par un
robot hackeur
qui avait sévit sur le site dernièrement en infestant tous les fichiers
php certainement par vol du passe ftp.
Les boucles relatives aux auteurs contenaient également toutes :
href="#URL_SITE_SPIP/spip.php?action=cookie&url=#URL_SITE_SPIP%2F#URL_ARTICLE&
ce qui avait échappé à mon premier nettoyage.
Juste pour en informer la liste.
Merci à ceux qui m'ont aidé.
A+
JPH
(et je ne sais plus comment ça se résoud ce truc...)
Bonjour,
Je constate aussi ce type de problème sur plusieurs spip (1.9.1 et 1.9.2 - à priori, pas de spip 2) hébergé sur nos serveurs.
Comme dans la discussion citée ci-dessus, je constate que ces problèmes arrivent surtout :
- dans les url vers les articles dans les flux rss
- dans les url (backend, plan, ...) calculées par #URL_PAGE
Ceci sur différents serveurs.
Pour s'en rendre compte une recherche : dans google sur « spip "spip.php/ecrire" » ou « spip "spip.php/IMG" » montre un paquet d'url de ce type...
Le comportement est aléatoire... recalculer la page ou vider le cache semble corriger la chose mais ça revient...
Les robots qui trouvent ces url les suivent et resuivent du coup sur des url tout aussi mauvaises...
J'en ai plein les logs.
J'ai cherché pas mal comment résoudre ce problème, mais je ne trouve pas de piste... Quelqu'un a une idée ?
provenait, non pas d'un réglage SPIP, mais de lignes ajoutées par un
robot hackeur
qui avait sévit sur le site dernièrement en infestant tous les fichiers
php certainement par vol du passe ftp.
Les boucles relatives aux auteurs contenaient également toutes :
href="#URL_SITE_SPIP/spip.php?action=cookie&url=#URL_SITE_SPIP%2F#URL_ARTICLE&
ce qui avait échappé à mon premier nettoyage.
Juste pour en informer la liste.
Merci à ceux qui m'ont aidé.
A+
JPH
Rebonjour,
Le temps que mon compte soit validé sur le serveur de liste et la solution arrive
Mais est-ce vraiment par ftp que se produisent ces changements ?
(cf. mon message de ce midi, je le constate sur beaucoup de sites).
J'ai posté trop vite, en fait, ce que je croyais résolu ne l'est pas et
le pb revient malgré le ménage.
Le 09/03/2010 18:28, Johan Pustoch a écrit :
Mais est-ce vraiment par ftp que se produisent ces changements ?
(cf. mon message de ce midi, je le constate sur beaucoup de sites).
De toute évidence, certainement
spyware récupérant les codes dans les fichiers xml de filezilla
(dans le cadre associatif, il y a plusieurs personnes qui ont l'accès
ftp - donc des machines pas forcément clean)
puis injection par robot d'un code identique dans tous les fichiers php.
et voilà.
J'ai posté trop vite, en fait, ce que je croyais résolu ne l'est pas et
le pb revient malgré le ménage.
Ce n'est donc pas par ftp... ? J'imagine que tu as changé les codes d'accès.
Le 09/03/2010 18:28, Johan Pustoch a écrit :
Mais est-ce vraiment par ftp que se produisent ces changements ?
(cf. mon message de ce midi, je le constate sur beaucoup de sites).
De toute évidence, certainement
spyware récupérant les codes dans les fichiers xml de filezilla
(dans le cadre associatif, il y a plusieurs personnes qui ont l'accès
ftp - donc des machines pas forcément clean)
puis injection par robot d'un code identique dans tous les fichiers php.
et voilà.
Mais là, je ne vois pas de code malveillant dans le code sources des site concernés... comme on en trouverait lors d'attaques...
J'ai vu un tel site attaqué en ftp, et les dégâts sont bien plus lourds... Via des attaques par injection également.
Exemple de site (je ne le gère pas directement - ici pas de transfert ftp suspects ) : http://www.lyc-poquelin-st-germain-laye.ac-versailles.fr/
(cf liens plan, agenda,... à gauche)
également le lien dans <link rel="alternate" ..., aussi le javascript de jquery,...
Je trouve 14 erreurs de ce type dans le source de la page d'accueil.
Ce n'est donc pas par ftp... ? J'imagine que tu as changé les codes
d'accès.
si, si, au départ il y a bien eu accès au document root et injection de
codes, mais il y a autre chose - si tu veux bien redescendre le fil pour
prendre connaissance de l'ensemble du pb qui concerne la génération
d'url à rallonge pour la quelle je n'ai pas encore la solution.
A+
JPH
Sur le site que je signalais hier (très touché par notre problème : 22000 requêtes de ce type pour ce seul site en 3 jours d'après les logs d'apache), j'ai constater que c'était surtout les robots de moteur de recherche qui intervenait.
J'ai l'impression, que ces robots créent le problème et l'accentuent en indexant de plus en plus de ce type de page.
Avec ces requêtes le cache de spip est alors spolié et on trouve alors le problème de liens dans le site public.
Ceci n'explique pas pourquoi le problème survient, mais explique le coté aléatoire du phénomène et son effet « boule de neige ».
Une solution que je teste aujourd'hui :
j'ai activé le .htaccess du spip en ajoutant la ligne suivante :
RewriteRule spip.php/ - [F]
J'ai mis la règle au niveau de la ligne où il y a :
# bloquer les acces aux repertoires .svn/ (SPIP, plugins, squelettes...)
Puis je vide le cache de spip.
Ainsi les requêtes « pourries » sont interdites. Le cache ne devrait plus être spolié.
J'espère :
- que cette règle ne crée pas d'effet de bord (!?)
- que ça règlera le problème !
- que les moteurs de recherche retireront les pages pourries de leur index
à suivre... je surveille...
Si ça marche, je l'appliquerai aux autres sites qui ont ce bug (et je pourrai même éventuellement appliquer la règle en amont sur notre proxy qui réparti les requêtes entre nos serveurs web.
Sur le site que je signalais hier (très touché par notre problème :
22000 requêtes de ce type pour ce seul site en 3 jours d'après les logs
d'apache), j'ai constater que c'était surtout les robots de moteur de
recherche qui intervenait.
J'ai l'impression, que ces robots créent le problème et l'accentuent en
indexant de plus en plus de ce type de page.
Avec ces requêtes le cache de spip est alors spolié et on trouve alors
le problème de liens dans le site public.
Ceci n'explique pas pourquoi le problème survient, mais explique le coté
aléatoire du phénomène et son effet « boule de neige ».
Une solution que je teste aujourd'hui :
j'ai activé le .htaccess du spip en ajoutant la ligne suivante :
RewriteRule spip.php/ - [F]
J'ai mis la règle au niveau de la ligne où il y a :
# bloquer les acces aux repertoires .svn/ (SPIP, plugins, squelettes...)
Puis je vide le cache de spip.
Ainsi les requêtes « pourries » sont interdites. Le cache ne devrait
plus être spolié.
J'espère :
- que cette règle ne crée pas d'effet de bord (!?)
- que ça règlera le problème !
- que les moteurs de recherche retireront les pages pourries de leur index
à suivre... je surveille...
Si ça marche, je l'appliquerai aux autres sites qui ont ce bug (et je
pourrai même éventuellement appliquer la règle en amont sur notre proxy
qui réparti les requêtes entre nos serveurs web).
j'ai activé le .htaccess du spip en ajoutant la ligne suivante :
RewriteRule spip.php/ - [F]
Pour interdire les accès des sites mauvais.com et pasbiengentil.com et
pasbiengentil.xxx
Ce n'est pas un problème de referer à exclure.
La règle que je propose ici exclu les pages dont l'url est mal fichue.
Il faut placer cette règle après « RewriteEngine on » comme tu le précises.
mais peut-être pourrais-tu poser ton pb dans un autre fil plus adapté à
ton cas.
Je ne comprends pas, je pensais que cela allait t'aider. J'ai bien l'impression que ton problème est identique. Relis mon message.
La solution que je propose semble fonctionner.
Je l'ai mise en place sur une trentaine de site depuis ce matin et je ne vois plus de problème avec des liens :
www.xxxx/spip.php/machin/truc/bidule/.../spip.php?page=...
Parmi ces trente sites, 4 d'entre eux généraient un traffic important de robots (googlebot, voilabot, exabot, baidu,...).
j'ai activé le .htaccess du spip en ajoutant la ligne suivante :
RewriteRule spip.php/ - [F]
La règle que je propose ici exclu les pages dont l'url est mal fichue.
Je ne comprends pas, je pensais que cela allait t'aider. J'ai bien
l'impression que ton problème est identique. Relis mon message.
Archt, désolé, j'étais branché, le nez dans le guidon, vers une
recherche dans le code liée au grand ménage que j'ai dû faire précédemment.
J'essaye ta solution, je te tiens au courant. Il se peut effectivement
que ce soit la bonne. Merci d'avoir insisté.
A+
JPH
j'ai activé le .htaccess du spip en ajoutant la ligne suivante :
RewriteRule spip.php/ - [F]
La règle que je propose ici exclu les pages dont l'url est mal fichue.
Je reviens sur ce fil.
J'ai placé RewriteRule spip.php/ - [F] dans le htaccess.
Le pb est toujours présent ce matin, mais les URL affichées sont
différentes.
J'ai regardé les logs qui indiquent bien le passage des robots
googlebot, etc. et qui portent bien la trace des url à rallonge, mais
ces passages existaient déjà avant et l'erreur ne se produisait pas.
Je constate qu'en vidant le cache, tout redevient à la normale, mais pas
pour bien longtemps.
J'utilise l'ancien format page pour les URL et il n'y a rien dans la base.
Les URL sont bien générées par SPIP et récupérées par les robots visiteurs ?
Ce ne sont pas les robots qui génèrent, donc un blocage par RewriteRule
ne peut que bloquer d'anciennes URL mémorisées et envoyées par les
robots, c'est bien ça ?
Le pb de génération se produit exclusivement avec les balises #URL_PAGE{nomdufichier}
et #LOGIN_PUBLIC.
Je te remercie Johan pour cette piste et je suis content que de ton
côté, cette solution ait enrayée les pb sur tes sites.
Aurais-tu une autre idée de la provenance de cette génération et comment
stopper tout ça ?
Pour le moment, la seule solution que j'aie est de supprimer les entrées
aux pages correspondantes (plan du site par exemple, qui est appelé par #URL_PAGE).
A+
JPH
Il neige sur la Franche-Comté !
j'ai activé le .htaccess du spip en ajoutant la ligne suivante :
RewriteRule spip.php/ - [F]
La règle que je propose ici exclu les pages dont l'url est mal fichue.
Je reviens sur ce fil.
J'ai placé RewriteRule spip.php/ - [F] dans le htaccess.
Le pb est toujours présent ce matin, mais les URL affichées sont
différentes.
J'ai regardé les logs qui indiquent bien le passage des robots
googlebot, etc. et qui portent bien la trace des url à rallonge, mais
ces passages existaient déjà avant et l'erreur ne se produisait pas.
Je constate qu'en vidant le cache, tout redevient à la normale, mais pas
pour bien longtemps.
Tu n'as pas un problème de cache ? Est-il bien vidé ?
J'utilise l'ancien format page pour les URL et il n'y a rien dans la base.
Les URL sont bien générées par SPIP et récupérées par les robots visiteurs ?
Ce ne sont pas les robots qui génèrent, donc un blocage par RewriteRule
ne peut que bloquer d'anciennes URL mémorisées et envoyées par les
robots, c'est bien ça ?
Le pb de génération se produit exclusivement avec les balises #URL_PAGE{nomdufichier}
et #LOGIN_PUBLIC.
Je te remercie Johan pour cette piste et je suis content que de ton
côté, cette solution ait enrayée les pb sur tes sites.
ça a l'air de tenir là.
Aurais-tu une autre idée de la provenance de cette génération et comment
stopper tout ça ?
Sur la provenance, non...
L'effet boule de neige explique ensuite le phénomène à mon avis...
Pour le moment, la seule solution que j'aie est de supprimer les entrées
aux pages correspondantes (plan du site par exemple, qui est appelé par #URL_PAGE).
Tu n'as pas un problème de cache ? Est-il bien vidé ?
oui semble-t-il
Quelle est l'adresse du site ?
www.shnd.fr
Depuis le vidage du cache, de ce matin, tout semble normal.
Sont concernés : les onglets de navigation supérieurs, plan du site, top
des 10 et espace adhérents.
Ne sont concernées que les balises #LOGIN-PUBLIC et #URL_PAGE
En vidant le cache tout revient à la normale. Il est inscrit "vide" mais
comment s'assurer que le cache est vide ?
De toute manière, ce n'est pas une solution de vider le cache
manuellement chaque jour.
Alors, si quelqu'un peut aider, merci.
A+
JPH
