Script php Anti aspirateur.

[hetzeld]

Pareil pour les .htaccess, l'user agent est totalement configurable et se fait passer pour un navigateur classique (quand le gars de mets pas un petit message sympa à la place)

Tout à fait d'accord, c'est ce que j'ai dit plus haut en répondant à Kmacleod.
C'est clair que ton script "anti-aspi" semble intéressant ! Tu peux m'inscrire sur ta liste si tu veux bien.

As-tu des infos telles que la charge CPU et le délai d'exécution du script?
J'imagine qu'il vaut mieux lui réserver sa propre base mySQL, non ?

A+

Dan

[Renardrouge]

J'ai un petit script php anti aspirateur pour ceux que ca interessent

Ca ne gêne pas le google full crawl ( beaucoup plus de requête que le daily crawl ) ? Si non, ton script m'interresse

Ca ne gêne pas car google et les robots indexeurs ne sont pas des "ratisseurs" de site. Ils font de nombreux acces mais largement repartis sur des journées entières. En plus ils ont plusieurs IP différentes. Donc ca déclenche pas le blackilistage. Au pire tu peux ajouter un controle sur l'IP avant de la blacklister si tu as un doute (mais pas sur le user agent hein).

Je t'envoie l'url en mp.

J'ai installé sur mon site un script qui génère un nombre infini de pages web aléatoires remplies avec plein d'adresses email inexistantes.

je préfère qu'il arrête l'aspiration le + vite possible plutot que de monopoliser des ressources pour ce genre de trucs. Au mieux le gars a perdu du temps (mais il s'en fout a mon avis, il effacera tout et poursuivra son chemin), au pire c'est ton serveur qui perd du temps avec lui.

Mais bon, chacun ses gouts.

[Renardrouge]

As-tu des infos telles que la charge CPU et le délai d'exécution du script?
J'imagine qu'il vaut mieux lui réserver sa propre base mySQL, non ?

Pour la base de données tu fais comme tu veux. Je ne sais pas vraiment si tu y gagneras quelque chose, j'utilise la meme que pour le restant du site.

J'ai pas vu de différence sur la charge SQL.
C'est 3 requetes en plus par page.
Il y a envrion 15 000 pages/jour chez moi.

A toi d'évaluer si ca vaut le coup par rapport aux ressources consommées.
Je vais refaire une version avec des tables MySQL en HEAP (en mémoire). Donc là ce sera encore moins gourmand. Il me faut quelques jours pour trouver le temps de le faire.

Ca reste moins gourmand, qu'un script comme les visiteurs ou un *nuke*bien sur

Ca ne prend quasiment pas de place, puisque tu as seulement 2 tables. Celle des IP bloquées, et celle des IP qui parcourt ton site dans la dernière minute (et qui se vide au fur et à mesure, il n'y a pas de log), pas de fioritures.

Tout tient en 30 lignes de codes php (en encore avec les accolades des if).
Il y a surement des améliorations possibles, mais je ne vois plus trop.
J'ai vraiment essayé de faire le plus simple possible.

[ortolojf]

Ben...

Les robots n'indexent que la page d'accueil, et aussi les 2 pages sur lesquelles cette page d'accueil a des liens.

De toute manière, le contenu de mon site dépend principalement des manipulations du visiteur, à savoir ce qu'il cherche, donc le contenu est très variable suivant les visites...

En gros, les statistiques sur les courses passées ( premier lien ), et les statistiques sur les courses du lendemain/après-midi (deuxième lien ).

C'est sûr qu'une fois qu'on est sur la page résultante, faut choisir la date des courses ( 1 ), ou la course à visualiser dans le cas ( 2 ).

Mon site est une pure merveille javascript:emoticon(':oops:') , tout en PHP et HTML fait main sous l'éditeur vi sous Linux RedHat7.3, ce fut un très gros travail, mais maintenant c'est terminé, ouf!...

Malheureusement, mes back-links viennent de chuter un petit peu, car le GoogleBot est passé entre 13h et 14h, heure à laquelle aucune course du lendemain n'est encore disponible, donc il a eu un message d'avertissement, qui ne comportait pas de lien vers la page d'accueil...

Dernier truc: Cà ne sert à rien d'aller sur mon site pour l'instant, je n'ai pas encore l'autorisation du PMU d'utiliser leurs résultats pour mettre à jour ma Base de Données, ce qui fait que celle-ci s'arrête au 31 décembre 2001. Les statistiques ne sont pas viables pour le moment... javascript:emoticon(':cry:')

Maiiisss, si vous voulez me visiter et me donner vos impressions, vous êtes les bienvenus! javascript:emoticon(':roll:')

Voilà, enfin, bien à vous.

Jean Francois Ortolo

[Renardrouge]

Bon pas plus d'entousiasme ou de retour que ca ?
Je pensais que ca interesserait plus de monde la lutte anti aspi pour etre franc.

Mais bon, je me trompe peut-être.

[deblok]

Renardrouge> Si si moi cela m'intéresse mais là je suis surcharger de travail. Je pense avoir plus de temps libre d'ici 1-2 semaines, donc je te recontacterai à ce moment là !

[Eservice]

Bonjour RenardRouge,

ton logiciel anti-aspi marche sans doute correctement.

J'ai décortiqué tes scripts et je t'envoie en MP des idées pour l'amélioration des performances ( une base de données plus petite, moins de requêtes sur le serveur MySQL, moins d'instructions sur le serveur PHP ), d'autant plus sensible que le traffic est élevé. Ceci dit je n'ai pas testé leur efficacité, je me fie à mon expérience.

[Renardrouge]

Hello,

Je viens de lire ton message, un grand merci pour les commentaires.
Comme j'ai retrouvé du boulot je garanti pas que je fais ca dans la soirée,
mais des que possible je m'y remet.

Je pense que tu as oublié les tables en heap pour les perf (mais sincèrement je ne sais pas si le script y gagnera enormément car il sera un peu plus complexe dans certains cas).

En tout cas merci encore. Je repasse dans quelques heures quand j'ai relu ton message et que je l'ai décortiqué un peu plus.

[Nitou]

Tenez nous au courrant !!

Ce script m'interesse bcp

[Renardrouge]

Dans son état actuel il marche déjà pas mal je trouve.

[Nitou]

sur mon site, il interfere avec le système d'activation de compte, j'ai du le désactivé

[Renardrouge]

heuuu intéressant, il fait ca comment ?

A priori il n'y a rien a voir avec autre chose (a moins d'avoir des tables avec le meme nom ou des variables communes peut-etre).

Ou alors tu des des pages qui se rechargent tres tres vite ? (dans ce cas augmente la limite).

Sincerement je ne vois pas comment il peut empecher un autre script de fonctionner correctement désolé.

[Eservice]

Il s'agit peut-être d'une tentative (extérieure) de flooding de ton activation de compte ... si si ça existe, mais ça n'est qu'une hypothèse

[Nitou]

Le phénomène est assez bizarre, je n'arrive pas à trouver l'erreur, je ne comprends d'ailleur pas pourquoi cela fait ça car le script est tout à fait différent de celui de l'activation.

[Eservice]

Les tables HEAP améliorent les performances mais elles ont des inconvénients : entre autres elles ne suportent pas les colonnes AUTO_INCREMENT.
Ensuite il n'est pas sûr que tous les hébergeurs les acceptent.