Mobiles et antiaspirateurs.

[ortolojf]

Bonjour

J'ai un anti-aspirateur sur mon site ( voir profil ).

Il détecte ( et laisse passer ) les moteurs de recherche, par leur url reverse.

L'adresse ip repérée, est : $_SERVER['REMOTE_ADDR'], et non pas le reste, qui est modifiable facilement.

Il marche très bien, mais pour les mobiles c'est galère, car pour une raison que je ne sais pas, il n'arrête pas de détecter des mobiles dont l'user-agent se termine par : "Presto/2.12.423 Version/12.16".

C'est à croire que ces mobile se partagent la même ip, qui est détectée trop souvent, donc filtrée.

Je reçois un mail à chaque blocage d'une ip.

Dans mon anti-aspirateur, les ips ne sont pas conservées ( ni envoyées par mail ), c'est leur hash code de type : sha256sum qui l'est.

Mais... Comment çà se fait que tant de mobiles se font bloquer par mon anti-aspirateur ?

Et... Si les adresses ip des mobiles peuvent être partagées ( voire attribuées plusieurs fois à deux mobiles différents ), comment résolvez-vous ce problème, avec vos anti-aspirateurs ?

Merci beaucoup de vos réponses.

Respectueusement.

 

[ybet]

Bonjour Ortolojf.

Le problème est un peu complexe. J'ai développé un anti-aspirateur pour mes sites en place depuis un peu plus de deux ans. Beaucoup d'appareils mobiles relisent l'adresse plusieurs fois pour paramétrer la résolution le mieux possibles. Du coup, ils lisent plusieurs fois la même page très rapidement.

Dans mon cas, je travaille sur 3 tables: 1 pour les robots détéctés au départ, une visiteur et une bloque. Pour faire passer une adresse IP visiteur -> bloqué, je n'analyse pas le nombre de pages vues dans un labs de temps mais bien le nombre de pages différentes (en fait sur 3)

$requete="select ip,date_heure from XXX WHERE ip='$ip'order by uid DESC limit 0,4";
$resultat=mysql_query($requete);
$ligne=mysql_num_rows($resultat);
//$erreur=mysql_error();
// print($erreur);

IF ($ligne>=3)
{
$valeur1=0;
$adresse=array();
$stamp=array();
// on récupère uniquement les fichier récupérés par la même IP
$requete="select filename,date_heure from visiteur WHERE ip='$ip' order by uid DESC limit 0,3";
$resultat=mysql_query($requete);
while ($tableau=mysql_fetch_array($resultat))
{
// ECHO "pages vues";
$adresse[$valeur1]=$tableau['filename'];
// echo $tableau['filename'];
$stamp[$valeur1]= strtotime($tableau['date_heure']);
// echo $valeur1." - ".$adresse[$valeur1]." - ".$stamp[$valeur1]."<br>";
$valeur1=$valeur1+1;

}
if(count(array_unique($adresse)) == $valeur1)
{
// toutes des pages différentes: copieurs? on analyse les délais.
// echo "toutes des pages différentes";
if ($stamp[0]-$stamp[2]<=8)
{
// 3 pages en moins de 8 secondes: on bloque
$bloque="O";
$requete="INSERT bloque SET ip='$ip',ipdecimal='$ipdecimal',ipdecimal_min='$ipdecimal',ipdecimal_max='$ipdecimal',bloque='$bloque'";
$resultat=mysql_query($requete);
// $erreur=mysql_error();
// print($erreur);
header("HTTP/1.1 403 Forbidden");
exit();
}

Désolé d'avoir un peu camouflé le code en gros, pour cette partie, 3 pages différentes vues en moins de 8 secondes (c'est paramétrés différents pour d'autres parties du site ou d'autres sites)- >transféré en ip bloquée et erreur 403 renvoyée.

Attention que ca oblige à vérifier manuellement les adresses bloquées ensuite: libéré des adresses qui semblent valides et bloquer définitivement d'une autre manière tout ce qui semble nettement copieurs: soit par htaccess, soit par iptables.

PS: un anti-aspirateur, c'est aussi dangereux pour des visiteurs standards.

 

[ortolojf]

Bonsoir Monsieur

Super merci pour votre réponse.

Je vais adapter mon anti-aspirateur le plus vite possible.

J'avais déjà adapté celui-ci, ( Trace IP V3, un logiciel de Astux ), pour ne mémoriser que les hash codes des ip.

Merci encore.

Maintenant mon site va avoir des visiteurs..

Respectueusement.

 

[ortolojf]

Bonjour ybet

Le problème est en train d 'être résolu.

Je suis en phase de test sur mon ordinateur.

J'ai constaté ( à mon grand étonnement ), que Chrome aspire dans une page, toutes les liens contenus dans la page.

Pour les pages de liste de courses, celà peut aller jusqu'à 9 x 8 = 72 liens différents ( nbre courses x nbre réunions ).

Je crains fort d'être obligé, de faire un traitement spécifique pour ces trois pages.

Ce sont les listes de courses :

- courses anciennes,
- courses du lendemain ou de l'après-midi,
- courses du soir ou de la veille.

Pas d'autre solution, quand ces pages sont chargées, de laisser Chrome aspirer les liens ( 75 pages différentes en une fraction de seconde ).

Mais... je peux envisager, de ne pas enregistrer ces pages chargées, quand la page chargée juste avant, est dans cette liste.

Donc... Quand la dernière page chargée est dans la liste, de manière très récente, ne pas mémoriser les liens susceptibles d'être chargés.

Mais... Je vais voir mécanisme exact, en fonction du comportement logique des visiteurs.

Ce problème, atteint toutes les pages contenant trop de liens.

Merci beaucoup de ton aide.

Respectueusement.

 

[ortolojf]

Bonjour ybet

Problème :

Chrome aspire tous les liens d'une page.

En celà, il se comporte comme un aspirateur.

Seule solution, pour différencier Chrome d'un aspirateur réel :

Réponse, : Il n'y a pas de solution... ;(

le User-Agent est modifiable.

Que faire ?

Merci beaucoup de ta réponse.

Respectueusement.

 

[ortolojf]

Rebonjour ybet

Le problème de Chrome semble virtuellement résolu.

Il utilise le mode "prerenderer" par défaut, pour tous les liens qu'il charge dans une page.

Ce mode "prerenderer" '( au lieu de "visible" ), peut être détecté en Javascript, par la "Page Visibility API", par l'état : "visibilityState".

Donc, mon auto-aspirateur sera en deux facettes : client et serveur, chacun avec un drapeau différent dans ma table MySQL : traceip_url.

Si Javascript est activé, le serveur le détectera et effacera toutes les urls avec son drapeau.

Sinon, le mode "prerenderer" est supposé non actif, et le soft se comporte comme d'habitude.

Qu'en penses-tu ?

Merci beaucoup de ta réponse.

Respectueusement.

 

[ybet]

Extension Chrome .... C'est un paramétrage chez toi mais pas pour les utilisateurs standards (sinon, tous les utilisateurs de Chrome seraient bloqués chez moi) et d'autres navigateurs (principalement mobiles) ont les mêmes options.

L'utilisation de javascript est très déconseillé:
1. les vrais aspirateurs ne suivent pas le javascript (qu'ils viennent de sites ou de logiciels aspirateurs).
2. l'envoi d'une commande client en javascript va ralentir le chargement des pages.

Ma solution, sans javascript fonctionne parfaitement contre tous ces parasites. Pas la peine de compliquer :wink:
T'envoit en MP le code complet du fichier d'analyse et de blocage. Merci de ne pas le divulguer .

Patrick

 

[ortolojf]

Extension Chrome .... C'est un paramétrage chez toi mais pas pour les utilisateurs standards (sinon, tous les utilisateurs de Chrome seraient bloqués chez moi) et d'autres navigateurs (principalement mobiles) ont les mêmes options.

L'utilisation de javascript est très déconseillé:
1. les vrais aspirateurs ne suivent pas le javascript (qu'ils viennent de sites ou de logiciels aspirateurs).
2. l'envoi d'une commande client en javascript va ralentir le chargement des pages.

Ma solution, sans javascript fonctionne parfaitement contre tous ces parasites. Pas la peine de compliquer :wink:
T'envoit en MP le code complet du fichier d'analyse et de blocage. Merci de ne pas le divulguer .

Patrick

Bonjour Monsieur

Celà va de soi, que le côté serveur détectera qu'il n'y pas d'urls chargées par le javascript ( s'il est désactivé ), et le serveur insérera ces urls ( avec le drapeau type serveur ), et en tiendra compte comme tu dis.

J'ai déjà mis le code php sur mon antiapirateur,je n'ai plus qu'à l'adapter à cette dernière modification.

Le paramétrage par défaut de Chrome, est de charger tous les liens des pages qu'il charge, mais seulement en mode "prereender".

Moi, je ne lancerai la mise à jour des urls ( drapeau client ), que si le mode est "visible".

Dans ce cas, ces urls seront visibles dans la table MySQL, et le soft côté serveur, tiendra compte de ces urls drapeau client ( et pas des drapeau serveur ), pour filtrer avec ta méthode.

Dans le cas contraire, ( Javascript non activé, ou Page Visibility API non disponible ), le soft côté serveur, ne tiendra compte que des urls drapeau serveur.

Le problème, était de différencier les chargements mode "prerenderer", des chargements réels.

Seuls les chargements réels doivent avoir de l'effet sur l'autoaspirateur.

Merci beaucoup de ton aide.

Respectueusement.

 

[ortolojf]

Bonjour ybet

J'ai mis en place le nouvel antiaspirateur.

J'ai suivi tes conseils pour le rythme des pages.

Sur mon site, le nombre de pages différentes chargées, s'affichent ( pour l'instant ), en haut de l'écran.

$vcpt1 = nombre de pages client,

$vcpt2 = nombre de pages serveur.

Celà fonctionne même si Javascript est désactivé, et/ou si le navigateur n'a pas la Page Visiblity API.

Si le visiteur a désactivé le Javascript, et que son navigateur charge les pages en mode "prerender", alors $vcpt1 est toujours égal à 0, et $vcpt2 peut dépasser le nombre maxi de pages.

Mais de toute façon mon site n'est même pas visible sans Javascript...

Pour les visiteurs pas pour les robots; .)

Merci beaucoup de ton aide.

Amicalement.