Hébergement rapide Prestashop

Prestashop 1.7 – Boostez votre hébergement (ép. 69)

Parfois il y a des choses qu’on ne soupçonne pas du tout, comme par exemple la saturation progressive de votre serveur par un mal invisible… du trafic indésirable, qui saturent les ressources de votre boutique Prestashop.

Avoir un bon serveur est important

Oui ça c’est forcément le 1er élément à prendre en compte, l’hébergement n’est pas un endroit sur lequel il faut économiser, car c’est lui qui va être le « socle » de votre boutique. Si l’hébergement n’est pas performant ou que vous avez une offre « discounter au rabais », il sera difficile d’obtenir de bonnes performances (temps de chargement, rapidité de réponse du serveur). Si vous devez investir à un endroit en priorité, c’est bien sur ce point… ne l’oubliez pas !

Des serveurs VPS au bord de la saturation

C’est ce que j’ai commencé à observer chez certains clients, c’est que la boutique Prestashop avait tendance à être lente… comme si la base de données MySQL était au bord de la saturation. Parfois ces boutiques étaient rapides et parfois très lentes… et on en revient à dire que cela doit être la faute de l’hébergeur (ce qui n’est pas tout à fait faux). On commence aussi à voir dans les logs du serveur des mentions « Too many connections » et là c’est l’inquiétude qui commence à monter…

Les robots tuent votre shop

En fait ces « bots » sont assez intelligents pour duper le serveur, ils ne spamment pas vos pages à 1000 affichages par secondes, mais viennent interroger votre serveur, chaque 30 ou 60 secondes… Quand il y’en a qu’un seul cela reste viable, mais si cela se démultiplie le serveur peut être grandement sollicité et les pages de votre Prestashop vont continuer à se charger… mais très lentement pour vos visiteurs. Cela crée un sentiment de frustration, car on se demande d’où vient la lenteur… alors qu’il semble qu’on a fait les choses en ordre.

Cloudflare

Pour certains clients j’ai déjà utilisé la solution Cloudflare qui permet de filtrer déjà en amont le trafic « déchet » et les tentatives intrusives / à risques. Le problème c’est que même Cloudflare laisse passer ces robots indésirables et se révèle donc impuissant face à ce type d’attaque… Par exemple pour moi « AhrefsBot » pour moi c’est clairement du SPAM… le site ahrefs n’a pas de raison de commencer à scanner n’importe quel autre site dans le but de l’analyser.

Et les hébergeurs dans tout ça ?

Bien souvent la réponse obtenue c’est que le problème se trouve plutôt du côté de la boutique en ligne… et cela est forcément agaçant pour le commerçant qui se trouve une fois de plus impuissant face à la situation. Ce que je peine à comprendre c’est que les hébergeurs ne proposent pas un filtre « automatique » sur tous ces robots connus comme « malsains » avec une liste automatiquement tenue à jour. Ce problème est récurrent et fait saturer beaucoup de serveurs… pourquoi ne pas proposer un tel filtrage de base… on serait tous gagnant non ?

Ressources

Pour ce tutoriel vous avez à disposition :

  • 1 x fichier de règles à ajouter à votre .htaccess
  • 1 x fichier « index.php » pour bloquer tous les types de robots

Télécharger

Résumé de la vidéo : bloquer les robots améliore la vitesse de Prestashop

  • Analyse d’un fichier de logs Apache avec les pages vues et type de bots. Chaque hébergement dispose de ce fichier de logs (vous pouvez y avoir accès via votre panel de gestion).
  • Utilisation de l’agent switcher chrome pour simuler la visite d’un robot.
  • Mise en place de règles dans le fichier « .htaccess » pour bloquer les robots connus (voir liste recommandée par Infomaniak).
  • Utilisation du fichier « index.php » et compréhension du code avec l’intégration de règles personnalisées pour bloquer tous les types de robots indésirables.
  • Je conseille de laisser tourner le fichier des logs pendant 1 ou 2 jours, puis ensuite vous pouvez faire une analyse pour voir s’il y a des indésirables / parasites permanents.

43 commentaires sur “Prestashop 1.7 – Boostez votre hébergement (ép. 69)”

    1. Hello,

      C’est vraiment super si cela fait une différence, cela prouve donc bien que beaucoup de site Prestashop sont pénalisés par ce fléau.

      A bientôt !

  1. Salut Germain
    C’est quand même dingue de voir tout ce qui se fait à notre insu …
    J’ai vu que certains, préconise de modifier le robot.txt pour bloquer les « bot » du style:
    User-agent: SemrushBot
    Disallow: /
    User-agent: SemrushBot-SA
    Disallow: /
    Mais ta méthode est intéressante, surtout pour ceux qui auraient tendance à régénérer le robot.txt via presta.
    Par contre, je me dis que de nouveaux robots ne manquerons pas d’apparaitre et qu’ils nous faut rester à l’affut de ces indésirables pour les ajouter à notre liste. Ne serait il pas possible d’autoriser les « bot » de notre choix et d’interdire tous les autres, ce serait plus simple.
    Mais bon je ne suis pas codeur …

    Merci pour ta perspicacité et le partage de connaissance.

    1. Hello,

      Il y a trop de risques d’autoriser « QUE » les bons bots, mon conseil c’est par exemple de se dire 1 x par mois on laisse tourner le script durant 24h et on regarde ce qui se passe (à noter dans l’agenda). La méthode avec l’index.php reste ma préférée, car elle est très efficace et on comprend facilement ce qui se passe.

      A bientôt !

  2. Bonjour,
    Une fois de plus, superbe tuto.
    J’ai 2 choses qui reviennent très souvent dans mon fichier log:
    bingbot et AppleWebKit. Puis-je les ajouter à la liste ou est-ce-que cela risque d’avoir un impact sur le référencement ?

    Bien cordialement.

    1. Bonjour,

      Ces deux-là vous pouvez les laisser… donc « bingbot » c’est le bot de Microsoft (même si c’est quelques % du marché, mieux vaut le laisser).

      A bientôt & merci !

  3. Rien à dire, tirs aussi efficace!!!

    Bien que je sois pas fan de la 1.7, et que le 80% des prestaUser sont en 1.6, il serai intéressant si cette méthode fonctionne aussi avec cette version.

    De plus, ils semble que l’hébergement est aussi voir autant important !!!

    Mais ce n’est que mon avis

    1. Hello,

      Oui alors la méthode du fichier « index.php » va fonctionner aussi pour Prestashop 1.6… donc tu peux l’appliquer sans problème pour réduire les attaques.

      A bientôt !

    1. Si cela ne fonctionne pas, vous pouvez commencer par activer le debug de Prestashop pour voir si une erreur est générée en arrière-plan.

      1. En fait, on dirait que le fait d’insérer les commandes dans le htaccess exactement comme indiqué, cela fait planter le site et dans ce cas évidement je n’ai plus accès au debug.
        Pourtant j’ai inséré scrupuleusement et juste après le rewrite engine on…
        Par contre en insérant le code dans le htaccess à la racine de l’hébergement, je n’ai pas d’erreur mais je ne sais pas si ça fonctionne. Je n’arrive pas à tester avec le user switch agent.
        Pourrais tu tester stp?
        J’ai normalement bloqué ahrefs, dotbot, semrushbot, sinon je vérifierai les logs demain.

        Merci

  4. Pour donner un petit retour, la methode qui a fonctionné pour moi est celle d’injecter le code suivant dans l’entête du htaccess (dans le repertoire de prestashop)

    #Anti-bots

    SetEnvIfNoCase User-Agent MJ12bot bad_bot
    SetEnvIfNoCase User-Agent AhrefsBot bad_bot
    SetEnvIfNoCase User-Agent YandexBot bad_bot
    SetEnvIfNoCase User-Agent SemrushBot bad_bot
    SetEnvIfNoCase User-Agent DotBot bad_bot
    SetEnvIfNoCase User-Agent Baiduspider bad_bot
    SetEnvIfNoCase User-Agent BLEXBot bad_bot

    Order Allow,Deny
    Allow from all
    Deny from env=bad_bot

    #ENDAnti-bots

    Je pense aussi que c’est le script qui consomme le moins de ressources dans un htaccess.
    Bon WE

    1. Hello,

      Oui c’est effectivement plus « rapide » niveau exécution (préserve aussi encore plus de ressource).

      Merci pour le retour d’expérience !

      1. Bonjour,
        ça fait 2 mois que j’ai mis en place le srcipt, au début j’utilise la méthode de germain, puis quand c’est des bots qui reviennent tout le temps, je met en place la méthode de youssef citée plus haut, ce qui me permet de laisser en place le script de germain sans avoir un fichier robotsDEBUG.txt de 50Go.
        Mais dans mes logs je vois ces robots revenir quand même exemple:
        [25/Jan/2020:11:27:16 +0100] « GET /robots.txt HTTP/1.1 » 403 360 « – » « Mozilla/5.0 (compatible; SemrushBot/6~bl; +http://www.semrush.com/bot.html) » « 20200125112716 »
        juste pour être sur, dans cet exemple le bot s’est bien pris une page 403, mais est ce que c’est normal que je le vois encore dans mes logs?
        Bien cordialement.

        1. Bonjour,

          Oui le BOT peut quand même toujours tenter d’accéder à votre hébergement, par contre dans le fichier de log, vous devriez avoir la mention « BLOCKED » pour le bot « SemrushBot ».

          A bientôt !

          1. Bonjour,
            oui dans le fichier de Log qui est créé avec le script, ça marquait bien BLOCKED, et comme j’ain dit plus haut pour faire moins gaspiler de ressources, après je met dans le htaccess deny from lenomdubot bad_bot
            du coup il ne s’écrit plus dans le fichier robotDEBUG.txt
            mais je le vois dans les vrais logs avec apparemment une page 403

  5. Salut Germain,

    Merci pour ce tuto que j’ai mis en place avec plaisir sur mon site.

    Une information sur les dates dont tu parles dans le tuto, peut-être que ça t’intéresse et que cela peut être utile à tes lecteurs.
    L’écriture des dates années-mois-jours permet simplement de classer facilement des dates par ordre chronologique en utilisant le tri alphabétique qui existe partout.
    Je l’utilise toujours pour mes fichiers, cela permet de s’y retrouver plus rapidement ;o).

    A+, Ruben

    1. Hello,

      Super, oui je l’ai mis en place aussi pour des clients et ça semble assez efficace le serveur sature beaucoup moins (en tout cas chez les clients où j’ai fait le test). Très juste, j’ai pas précisé mais dans les bases de données le format utilisé est effectivement YYYY-MM-DD ce qui permet de faire un classement croissant / décroissant facilement.

      A bientôt !

    1. Hello,

      Merci pour la contribution, voilà une ressource intéressante qui peut faire gagner du temps plutôt que de faire par « déduction » et tester chaque robot… A garder en tête pour un futur potentiel TUTO Prestashop 😉

      A bientôt !

  6. Sympa Merci pour l’astuce
    mais je trouve dommage de bloquer les bot SEO comme « SemrushBot »
    pourquoi ne pas faire une règle ou ont les bloques par exemple uniquement la journée de 05H30 à 00H30

    /* Webbax - TUTO 69 - Sécurité antibots */
    $logs = true;
    $heure = date('Hi');
    if($logs){
        $filename = "BOT.log";
        $log_file = fopen($filename, "a+") or die("Unable to open file!");
    }
    
    $bad_bots = array('AhrefsBot','SEOkicks','SemrushBot');
    $user_agent = $_SERVER['HTTP_USER_AGENT']."\n";
    
    if($logs){
        fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent );
        fclose($log_file);
    }
    
    foreach($bad_bots as $bad_bot){
            if ($heure >= 0530 && $heure <= 0030){
                    if(strpos($user_agent,$bad_bot)!==false){
                            if($logs){
                                    $log_file = fopen($filename,"a+") or die("Unable to open file!");
                                    fwrite($log_file,date('Y-m-d H:i:s').' - '."BLOCKED : ".$bad_bot."\n");
                                    fclose($log_file);
                            }
                            die('blocked bot');
                    }
            }
    }
    /* --- */
    
    1. Hello,

      C’est une très bonne remarque… pourquoi ? Et bien parce que je n’y ai pas pensé ahaha… Un grand merci d’avoir contribué à ce tutoriel Prestashop !

      A bientôt !

  7. Bonjour, merci pour ces infos. Je viens de voir que j’ai beaucoup de visiteur et d’ajout au panier, mais avec des robot. Cela doit jouer énormément sur le taux de rebond, non?
    Je suis avec la 1.6.1, la solution suivante fonctionne t-elle?
    #Anti-bots
    SetEnvIfNoCase User-Agent MJ12bot bad_bot
    SetEnvIfNoCase User-Agent AhrefsBot bad_bot
    SetEnvIfNoCase User-Agent YandexBot bad_bot
    SetEnvIfNoCase User-Agent SemrushBot bad_bot
    SetEnvIfNoCase User-Agent DotBot bad_bot
    SetEnvIfNoCase User-Agent Baiduspider bad_bot
    SetEnvIfNoCase User-Agent BLEXBot bad_bot
    Order Allow,Deny
    Allow from all
    Deny from env=bad_bot
    #ENDAnti-bots

    Je vois aussi le passage de semruch, aref, des robot de lituanie et taiwan. Y a du monde quand même!
    Merci pour toutes vos informations qui pourrons m’aider à balayer ces robot nuisant mais en gardant les bons pur le référencement 😉
    Merci pour vos informations

  8. Bonjour Germain,
    Il y a quelques semaines j’ai installé le code et je me suis aperçu que ma page d’accueil était « blocked bot » ainsi que des onglets, j’ai donc supprimé le code mais « blocked bot » est têtu et s’affiche de temps à autre, il faut que je rafraîchisse plusieurs fois la page pour qu’elle s’affiche enfin, j’ai supprimé tous les caches des navigateurs que j’utilise ainsi que le cache de Prestashop, j’ai même supprimé dans le répertoire var/cache/ le dossier Prod.
    Si tu as une explication ou solution je suis preneur…
    Merci d’avance pour ton aide… à bientôt

    1. Hello,

      Hum, délicat… je commencerais par retirer « intégralement » le code concernant le blocage des bots pour voir comment Prestashop réagit. Ensuite, dans la variable $bad_bots essaie de mettre uniquement un seul nom de bot pour commencer (afin de pouvoir identifier d’où vient le problème).

      A bientôt !

        1. Bonjour Germain,
          j’ai testé, mais rien n’y fait, j’ai donc supprimé absolument tout le code dans le .htaccess et le fichier index.php, mais rien n’y fait j’ai toujours des pages « blocked bot » sur la page d’accueil et les onglets qui ramènent à ma page d’accueil… Au secours !!!
          Merci d’avance pour ton aide… à bientôt

          1. efface le cache de ton navigateur et celui de prestashop dans parametres avancés > Performances > vider le cache
            😉

  9. Bonjour zstof,
    j’ai déjà tout fait cache navigateur, Prestashop j’ai même supprimé les deux dossiers cache dans var, rien n’y fait ???

    1. Bonjour,

      Difficile d’en dire plus, si le code n’est plus présent il ne peut pas continuer à s’exécuter (ou alors le code n’a pas été retiré correctement). Ce que vous pouvez faire éventuellement c’est de vérifier à nouveau en contrôlant ce fichier (l’index.php Prestashop situé à la racine) le télécharger avec Filezilla, l’ouvrir et vérifier que le code antibot pour n’est plus présent.

      A bientôt !

      1. Bonjour Germain,
        j’ai tout simplement retiré le code et tout est rentré dans l’ordre, je pense…
        Jusqu’à aujourd’hui je n’ai plus de pages « blocked bot », croisons les doigts.
        Merci pour ton aide et à bientôt !

  10. Salut Webbax.
    J’ai souhaité te demander une petite chose parce que j’en suis techniquement incapable. Je l’aurais bien fais par mail, mais je me suis dit que la réponse à ma question pourrait intéresser du monde.
    Je m’explique (oui, je suis bavard, mais j’aime bien expliquer le contexte afin que ceux qui passent derrière et qui lisent la réponse saches si ce qui est dit peut les concerner aussi).
    Voici donc le truc…
    J’utilise ta technique sur tout mes sites, et ça marche du tonnerre. Ca marche tellement bien que grâce à elle j’ai pu repérer des tentative de piratage de mon site que je n’aurai pas vu autrement.
    Dans le fichier RobotDebug.txt j’ai trouvé des « Python-request »… et j’ai trouvé celà bizarre. Je suis donc allé jeter un oeil dans les fichiers logs et j’ai pu trouvé un « modus-operendi » qui se répète à intervalles totalement aléatoire (soit c’est le même hacker qui fait celà à des moments différents, soit plusieurs hackers utilisent la même technique, je ne sais pas).
    Et ça se reproduit à chaque fois selon le même procédé et à chaque fois avec deux adresses IP différentes, mais c’est le mode opératoire qui a attiré mon attention.
    Tout d’abord, j’ai des requêtes avec python-request, et ensuite, avec une autre adresse IP la tentative de hack (je ne sais pas si les deux sont vraiment liés, mais la répétition du schéma et statistiquement faible).

    J’illustre ça avec les extrait des logs :
    Etape 1 : Python-request

    - 35.202.11.0 - - [15/Apr/2020:02:05:38 +0200] "GET / HTTP/1.1" 200 21897 XXX-XXX.com "-" "python-requests/2.23.0" "-"
    
    - 35.202.11.0 - - [15/Apr/2020:02:05:32 +0200] "GET /robots.txt HTTP/1.1" 200 3242 XXX-XXX.com "-" "python-requests/2.23.0" "-"
    
    - 35.202.11.0 - - [15/Apr/2020:02:05:32 +0200] "GET / HTTP/1.1" 301 20 XXX-XXX.com "-" "python-requests/2.23.0" "-"
    

    Etape 2 : Tentative de hack avec une autre adresse IP

    123.57.6.0 - - [15/Apr/2020:02:28:22 +0200] "GET /login.action HTTP/1.1" 404 823 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-"
    
    123.57.6.0 - - [15/Apr/2020:02:28:23 +0200] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-"
    
    123.57.6.0 - - [15/Apr/2020:02:28:23 +0200] "GET / HTTP/1.1" 200 229 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-"
    
    123.57.6.0 - - [15/Apr/2020:02:28:24 +0200] "GET /horde/imp/test.php HTTP/1.1" 404 823 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-"
    
    123.57.6.0 - - [15/Apr/2020:02:28:25 +0200] "GET /login?from=0.000000 HTTP/1.1" 404 823 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-"
    
    123.57.6.0 - - [15/Apr/2020:02:28:25 +0200] "GET /console HTTP/1.1" 404 823 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-"
    
    123.57.6.0 - - [15/Apr/2020:02:28:26 +0200] "GET /cgi-bin/test-cgi HTTP/1.1" 404 823 217.160.120.163 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0" "-".
    

    Et ca se reproduit

    107.174.244.0 - - [15/Apr/2020:11:53:44 +0200] "GET /muieblackcat HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    
    107.174.244.0 - - [15/Apr/2020:11:53:44 +0200] "GET //phpMyAdmin/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    
    107.174.244.0 - - [15/Apr/2020:11:53:45 +0200] "GET //phpmyadmin/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    
    107.174.244.0 - - [15/Apr/2020:11:53:45 +0200] "GET //pma/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    
    107.174.244.0 - - [15/Apr/2020:11:53:45 +0200] "GET //myadmin/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    
    107.174.244.0 - - [15/Apr/2020:11:53:45 +0200] "GET //MyAdmin/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    
    107.174.244.0 - - [15/Apr/2020:11:53:46 +0200] "GET //PhpMyAdmin/scripts/setup.php HTTP/1.1" 404 823 217.160.120.163 "-" "-" "-"
    

    Alors… tu vas surement te demander en quoi tu peux m’aider, surtout que la plupart des requêtes sont bloquées par le module SecurityPro qu’on a installé.

    Mais c’est que j’aimerai essayer de pousser un peu plus loin les investigations, et même si, je sais très bien que les hacker passent par des proxy ou des VPN ou ne sais quoi encore pour masquer leur IP, la loi française interdit au fournisseur d’accès de nous fournir les adresse IP précises. Elles sont toutes anonymisées en se terminant par un .0

    Ma question serait donc juste de savoir quel code ou quelle modification il faudrait apporter à ton script pour qu’il nous fournisse l’adresse IP précise en plus des informations qu’on à déjà (un peu comme dans les fichiers logs … mais avec la précision qui leur manque).
    Penses tu que ce soit quelque chose de réalisable?

    Et dans le même temps, si tu pouvais m’expliquer exactement ce que signifient ces requêtes python-request, ca pourrait être sympa d’avoir cette info, parce qu’avec ton script on peut bloquer plein de choses (j’ai pu bloquer un spammeur qui utilisait un très vieux site que j’avais fait en html sans captcha (à l’époque c’était inutile) et le gars utilisait supersendme… que j’ai rajouté dans ton script et maintenant quand ça se produit il est marqué comme « blocked ».

    Donc, du coup, j’ai également rajouté « python-request » depuis aujourd’hui dans la liste sur le site prestashop, mais en même temps, je me demande si je ne vais pas bloquer d’autres choses indispensables… vois tu mon soucis?
    Je te remercie pour le temps que tu pourras consacrer à ma question.
    Jérôme

    1. Hello,

      A vrai dire je ne sais pas exactement à quoi ça correspond ces « python-request », mais on va dire que ce n’est pas vraiment standard… Certainement qu’un système extérieur interroge le shop, mais dans quel but… (bonne question). Tu as bien fait de tester le blocage avec la règle, pour afficher aussi l’IP il faut utiliser « REMOTE_ADDR » voir ici : https://www.codexworld.com/how-to/get-user-ip-address-php/

      A bientôt !

  11. Salut,
    Je suis un utilisateur comme toi du script mis à disposition par Webbax, ton message ma interpelais car je trouve également des requêtes de type python:

    "python-requests/2.18.1"
    "python-requests/2.23.0"
    "python-requests/2.18.1"
    

    etc..

    une simple recherche sur google aurait pu de donner la réponse:
    « Cette chaîne d’agent utilisateur appartient à python-requests, qui est une bibliothèque utilisée pour effectuer des requêtes HTTP (le plus souvent, en mode automatique en tant que robot d’indexation Web ou bot) »

    1. J’ai fais les recherches. Et si j’ai bien trouvé les informations que tu mentionnes (merci beaucoup pour d’avoir pris le temps de me rédiger une réponse), j’ai aussi trouvé des informations contradictoires ou du moins incomplètes, puisque le premier lien que m’a fourni google menait sur un outils qui permettait de tester les failles (PenTest il me semble), et que par conséquent n’étant sûr de rien, et ayant, suite à ces potentiel Pentest, les tentatives de piratages, j’avais besoin d’avoir confirmation si c’était dangereux ou non, et quelles seraient les conséquences de rajouter python-request dans la liste des éléments à bloquer.

      Et d’autre part, j’ai toujours besoin de savoir comment récupérer les adresse IP dans le script de Webbax pour qu’elles apparaissent en tête de ligne dans le fichier robotdebug.txt.
      Mais encore une fois, merci de m’avoir apporter cette première réponse.

      1. Concernant les python-request je sais que si tu les bloques tu risque d’empêcher tous les site comme semrush , majestic, etc.. qui eux utilise ce genre de bot et certaine API aussi
        sinon Tu peux récupérer l’adresse ip d’un visiteur en ajoutant cette ligne:

        echo ‘adresse IP : ‘.$_SERVER[‘REMOTE_ADDR’];

    2. Hello,

      Merci d’avoir fait ce retour je pense que c’est très intéressant pour ceux qui liront ce billet par la suite 😉

      A bientôt !

  12. C’est bon, j’y suis arrivé. En croisant avec un autre extrait d’un script que j’ai trouvé en ligne.
    En fait, après

    $user_agent = $_SERVER['HTTP_USER_AGENT']."\n";
    

    Je remplace :

    if($logs){
        fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent );
        fclose($log_file);
    

    Par :

    $ip = $_SERVER["REMOTE_ADDR"];
     if ($deep_detect) {
                if (filter_var(@$_SERVER['HTTP_X_FORWARDED_FOR'], FILTER_VALIDATE_IP))
                    $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
                if (filter_var(@$_SERVER['HTTP_CLIENT_IP'], FILTER_VALIDATE_IP))
                    $ip = $_SERVER['HTTP_CLIENT_IP'];
            }
            
    if($logs){
        fwrite($log_file,date('Y-m-d H:i:s').' - '.$user_agent. $ip.' - ');
        fclose($log_file);
    }
    

    Et dans le fichier Robotdebug.txt j’obtiens ceci :

    77.111.244.209 - 2020-04-17 11:20:04 - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
    

    Donc, pour ceux qui voulaient m’aider, ce n’est plus la peine de chercher (si vous le faisiez encore) et ZStof, merci pour ta suggestion qui m’a mis sur la voie.

    Et pour ceux que ca intéresse, eh bien vous avez, vous aussi la solution.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *