Mobiles et antiaspirateurs.

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.