Mobiles et antiaspirateurs.

Discussion dans 'Développement d'un site Web ou d'une appli mobile' créé par ortolojf, 23 Mai 2015.

  1. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39
    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.
     
  2. ybet
    ybet WRInaute accro
    Inscrit:
    22 Novembre 2003
    Messages:
    7 419
    J'aime reçus:
    1
    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)

    Désolé d'avoir un peu camouflé le code :oops: 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.
     
  3. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39
    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.
     
  4. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39
    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.
     
  5. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39
    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.
     
  6. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39
    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.
     
  7. ybet
    ybet WRInaute accro
    Inscrit:
    22 Novembre 2003
    Messages:
    7 419
    J'aime reçus:
    1
    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
     
  8. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39

    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.
     
  9. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 677
    J'aime reçus:
    39
    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.
     
Chargement...
Similar Threads - Mobiles antiaspirateurs Forum Date
fichiers PDF non adaptés aux mobiles Débuter en référencement 17 Novembre 2021
Menu pour mobiles et tablette Développement d'un site Web ou d'une appli mobile 19 Janvier 2021
Données mobiles absentes de Google Analytics Google Analytics 22 Octobre 2020
Quel futur proche pour les e-paiements mobiles ? e-commerce 9 Septembre 2019
fichier PDF et "Votre page n'est pas adaptée aux appareils mobiles" Développement d'un site Web ou d'une appli mobile 5 Septembre 2019
Astuce Image dans les résultats mobiles YouTube, Google Images et Google Maps 13 Juin 2019
Pub Adsense n'apparait pas sur certains mobiles AdSense 10 Avril 2019
Seules mes URL mobiles sont référencées Problèmes de référencement spécifiques à vos sites 6 Novembre 2018
2018 sera les Progressive Web Apps et fin des apps mobiles Développement d'un site Web ou d'une appli mobile 28 Décembre 2017
Compatibilité mobiles - ordis de bureaux Demandes d'avis et de conseils sur vos sites 5 Juillet 2017
Pages adaptées pour mobiles ou non ? Crawl et indexation Google, sitemaps 23 Juin 2017
Ou héberger des applications mobiles ? avec conseil tech. Développement d'un site Web ou d'une appli mobile 21 Janvier 2017
Détection des mobiles, pour AMP Google : l'entreprise, les sites web, les services 12 Décembre 2016
Google index "mobile first" : désindexer les sites mobiles light ? Crawl et indexation Google, sitemaps 29 Novembre 2016
Comment aider Google bot à revenir sur mes pages mobiles ? Crawl et indexation Google, sitemaps 16 Octobre 2016
Google veut imposer le responsive design aux sites mobiles Référencement Google 14 Octobre 2016
Google teste des images miniatures dans les résultats mobiles Référencement Google 16 Septembre 2016
Message [Votre page n'est pas adaptée aux appareils mobiles] dans les SERP Référencement Google 31 Août 2016
Développer des applications mobiles Développement d'un site Web ou d'une appli mobile 10 Septembre 2015
Webmaster tool débloque (pages mobiles fantômes) Référencement Google 4 Juin 2015