Comment puis-je empêcher le raclage du site?

Question

J'ai un site Web assez volumineux avec une grande base de données d'artistes. J'ai remarqué que d'autres sites de musique effaçaient les données de notre site (j'entre des noms d'artistes factices ici et là, puis je les recherche sur Google).

Comment puis-je empêcher le grattage de l'écran? Est-ce même possible?

Answer 1

Remarque: Étant donné que la version complète de cette réponse dépasse la limite de longueur de Stack Overflow, vous devez dirigez-vous vers GitHub pour lire la version étendue, avec plus de conseils et de détails.

---

Pour empêcher le grattage (également connu sous le nom de Webscraping , ), la capture d'écran , de l'exploration de données Web , Web Harvesting , ou extraction de données Web ), il est utile de savoir comment fonctionnent ces racleurs et, par extension, ce qui les empêche de bien fonctionner.

Il existe différents types de grattoirs, et chacun fonctionne différemment:

• Les araignées, telles que le bot de Google ou les copieurs de sites Web tels que HTtrack , qui suivent récursivement les liens vers d'autres pages afin d'obtenir des données. Celles-ci sont parfois utilisées pour un grattage ciblé afin d'obtenir des données spécifiques, souvent en combinaison avec un analyseur HTML pour extraire les données souhaitées de chaque page.

• Scripts de shell: Parfois, des outils Unix courants sont utilisés pour le nettoyage: Wget ou Curl pour télécharger des pages et Grep (Regex) pour extraire les données.

• Analyseurs HTML, tels que ceux basés sur Jsoup, Scrapy , et autres. Semblables à ceux basés sur les expressions rationnelles basées sur le script Shell, ils fonctionnent en extrayant des données de pages basées sur des modèles en HTML, ignorant généralement tout le reste.

  Par exemple: si votre site Web dispose d'une fonctionnalité de recherche, un tel racleur peut soumettre une demande de recherche, puis extraire tous les liens de résultats et leurs titres à partir de la page de résultats HTML, afin d'obtenir spécifiquement uniquement les liens de résultats de recherche et leurs titres. . Ce sont les plus communs.

• Screenscrapers, basés par exemple sur. Selenium ou PhantomJS , qui ouvre votre site Web dans un vrai navigateur, exécutez JavaScript, AJAX, etc., puis obtenez le texte souhaité de la page Web, généralement par:

  • Obtenir le code HTML à partir du navigateur une fois votre page chargée et l'exécution de JavaScript, puis utiliser un analyseur HTML pour extraire les données souhaitées. Celles-ci sont les plus courantes et la plupart des méthodes permettant de décomposer les analyseurs/séparateurs HTML fonctionnent également ici.

  • Prendre une capture d'écran des pages rendues, puis utiliser OCR pour extraire le texte souhaité de la capture d'écran. Celles-ci sont rares, et seuls les scrapeurs dédiés qui souhaitent réellement disposer de vos données peuvent le configurer.

• Services de Webscraping tels que ScrapingHub ou Kimono . En fait, il y a des personnes dont le travail consiste à déterminer comment extraire votre site et à en extraire le contenu pour que d'autres puissent l'utiliser.

  Sans surprise, les services professionnels de raclage sont les plus difficiles à dissuader, mais si vous prenez le temps nécessaire pour trouver comment gratter votre site, ceux-ci (et les personnes qui les paient pour le faire) ne seront peut-être pas dérangés pour gratter votre site.

• Incorporation de votre site Web dans les pages d'autres sites avec frames , et intégration de votre site dans des applications mobiles.

  Bien qu'elles ne soient pas techniquement adaptées, les applications mobiles (Android et iOS) peuvent intégrer des sites Web et injecter du code CSS et JavaScript personnalisé, modifiant ainsi totalement l'apparence de vos pages.

• Copier-coller humain: les gens vont copier et coller votre contenu afin de l'utiliser ailleurs.

Il existe beaucoup de chevauchement entre ces différents types de grattoirs et de nombreux grattoirs se comporteront de la même manière, même s'ils utilisent des technologies et des méthodes différentes.

Ces astuces concernent principalement mes propres idées, diverses difficultés que j'ai rencontrées lors de l'écriture de grattoirs, ainsi que des informations et des idées venant des internautes.

Comment arrêter de gratter

Vous ne pouvez pas l’empêcher complètement , car quoi que vous fassiez, les racleurs déterminés peuvent toujours comprendre comment gratter. Cependant, vous pouvez arrêter beaucoup de raclage en faisant quelques choses:

Surveillez vos journaux et vos modèles de trafic; limiter l'accès si vous voyez une activité inhabituelle:

Consultez régulièrement vos journaux et, en cas d'activité inhabituelle indiquant un accès automatisé (racleurs), telle que de nombreuses actions similaires à partir de la même adresse IP, vous pouvez bloquer ou limiter l'accès.

Plus précisément, quelques idées:

• Limitation du débit:

  N'autorisez que les utilisateurs (et les scrapers) à effectuer un nombre limité d'actions au cours d'une période donnée. Par exemple, n'autorisez que quelques recherches à la seconde à partir d'une adresse IP ou d'un utilisateur spécifique. Cela ralentira les racleurs et les rendra inefficaces. Vous pouvez également afficher un captcha si les actions sont terminées trop rapidement ou plus rapidement qu’un utilisateur réel.

• Détecter une activité inhabituelle:

  Si vous constatez une activité inhabituelle, telle que de nombreuses requêtes similaires émanant d'une adresse IP spécifique, une personne regardant un nombre excessif de pages ou effectuant un nombre inhabituel de recherches, vous pouvez empêcher l'accès ou afficher un captcha pour les requêtes suivantes.

• Ne vous contentez pas de surveiller et limiter le débit par adresse IP - utilisez également d'autres indicateurs:

  Si vous bloquez ou limitez la limite de débit, ne le faites pas simplement par adresse IP; vous pouvez utiliser d'autres indicateurs et méthodes pour identifier des utilisateurs ou des racleurs spécifiques. Parmi les indicateurs pouvant vous aider à identifier des utilisateurs/racleurs spécifiques, citons:

  • À quelle vitesse les utilisateurs remplissent-ils des formulaires et où sur un bouton ils cliquent;

  • Vous pouvez collecter de nombreuses informations avec JavaScript, telles que la taille/résolution de l'écran, le fuseau horaire, les polices installées, etc. vous pouvez l'utiliser pour identifier les utilisateurs.

  • En-têtes HTTP et leur ordre, en particulier User-Agent.

  Par exemple, si vous recevez plusieurs demandes provenant d’une même adresse IP, toutes utilisant le même agent d’utilisateur, la taille de l’écran (déterminée avec JavaScript), et l’utilisateur (scraper dans ce cas) clique toujours sur le bouton de la même manière et à intervalles réguliers, c'est probablement un grattoir d'écran; et vous pouvez bloquer temporairement des requêtes similaires (par exemple, bloquer toutes les requêtes avec cet agent utilisateur et la taille de l'écran provenant de cette adresse IP particulière), et ainsi vous ne gênerez pas les vrais utilisateurs de cette adresse IP, par exemple. en cas de connexion internet partagée.

  Vous pouvez également aller plus loin, car vous pouvez identifier des demandes similaires, même si elles proviennent d'adresses IP différentes, indiquant un raclage distribué (racleur utilisant un botnet ou un réseau de mandataires). Si vous recevez beaucoup de demandes identiques par ailleurs, mais qu'elles proviennent d'adresses IP différentes, vous pouvez bloquer. Encore une fois, soyez conscient de ne pas bloquer par inadvertance de vrais utilisateurs.

  Cela peut être efficace contre les écrans de scènes utilisant JavaScript, car vous pouvez obtenir beaucoup d’informations à leur sujet.

  Questions connexes sur Security Stack Exchange:

  • Comment identifier de manière unique les utilisateurs avec la même adresse IP externe? pour plus de détails, et

  • Pourquoi les gens utilisent-ils des interdictions d'adresse IP lorsque les adresses IP changent souvent? pour plus d'informations sur les limites de ces méthodes.

• Au lieu de bloquer temporairement l'accès, utilisez un Captcha:

  Le moyen le plus simple de mettre en œuvre la limitation de débit serait de bloquer temporairement l'accès pendant un certain temps. Toutefois, l'utilisation d'un Captcha peut être préférable, voir la section Captchas plus bas.

Nécessite une inscription et une connexion

Exigez la création d'un compte pour afficher votre contenu, si cela est possible pour votre site. C'est un bon moyen de dissuasion pour les racleurs, mais également pour les vrais utilisateurs.

• Si vous avez besoin de créer un compte et de vous connecter, vous pouvez suivre avec précision les actions des utilisateurs et des opérations de nettoyage. De cette façon, vous pouvez facilement détecter quand un compte spécifique est utilisé pour le nettoyage et l'interdire. Des éléments tels que la limitation du taux ou la détection des abus (par exemple un grand nombre de recherches en un temps record) deviennent plus faciles, car vous pouvez identifier des scrapers spécifiques plutôt que des adresses IP.

Afin d'éviter que les scripts créent de nombreux comptes, vous devez:

• Demandez une adresse électronique pour l'enregistrement et vérifiez-la en envoyant un lien à ouvrir pour activer le compte. N'autorisez qu'un seul compte par adresse électronique.

• Exiger qu'un captcha soit résolu lors de l'enregistrement/création du compte.

Exiger la création d'un compte pour afficher le contenu éloignera les utilisateurs et les moteurs de recherche; si vous avez besoin de créer un compte pour voir un article, les utilisateurs iront ailleurs.

Bloquez l'accès depuis les adresses d'hébergement et de nettoyage de votre cloud

Parfois, les scrapers seront exécutés à partir de services d’hébergement Web, tels que Amazon Web Services, GAE ou VPS. Limitez l'accès à votre site Web (ou affichez un captcha) pour les demandes provenant des adresses IP utilisées par ces services d'hébergement en nuage.

De même, vous pouvez également limiter l'accès aux adresses IP utilisées par les fournisseurs de proxy ou VPN, car les scrapers peuvent utiliser ces serveurs proxy pour éviter la détection de nombreuses demandes.

Attention, en bloquant l'accès des serveurs proxy et des VPN, vous affecterez négativement les utilisateurs réels.

Rendez votre message d'erreur indéfinissable si vous bloquez

Si vous bloquez/limitez l'accès, vous devez vous assurer que vous ne dites pas au racleur la cause du blocage, en lui donnant ainsi des indices sur la façon de réparer son racleur. Donc, une mauvaise idée serait d'afficher des pages d'erreur avec du texte comme:

• Trop de demandes de votre adresse IP, veuillez réessayer plus tard.

• Erreur, en-tête de l'agent utilisateur non présent!

Au lieu de cela, affichez un message d'erreur convivial qui ne dit pas au racleur ce qui l'a causé. Quelque chose comme cela est beaucoup mieux:

• Désolé, quelque chose s'est mal passé. Vous pouvez contacter le support via [email protected] si le problème persiste.

C'est également beaucoup plus convivial pour les vrais utilisateurs, s'ils voient jamais une telle page d'erreur. Vous devriez également envisager de montrer un captcha pour les requêtes suivantes au lieu d'un blocage matériel, au cas où un utilisateur réel verrait le message d'erreur, afin que vous ne bloquiez pas et que les utilisateurs légitimes ne vous contactent pas.

Utilisez Captchas si vous pensez que votre site Web est accédé par un grattoir.

Les Captchas ("Test entièrement automatisé pour distinguer les ordinateurs des personnes") sont très efficaces contre l’arrêt des scrapers. Malheureusement, ils sont également très efficaces pour irriter les utilisateurs.

En tant que tels, ils sont utiles lorsque vous soupçonnez un éventuel racleur et que vous souhaitez arrêter le raclage, sans bloquer l'accès au cas où ce ne serait pas un racleur, mais un véritable utilisateur. Vous pouvez envisager de montrer un captcha avant d'autoriser l'accès au contenu si vous suspectez un scraper.

Éléments à prendre en compte lors de l’utilisation de Captchas:

• Ne roulez pas vous-même, utilisez quelque chose comme Google reCaptcha : C’est beaucoup plus facile que de mettre en place un captcha vous-même, c’est plus convivial que certaines solutions de texte floues et déformées que vous pourriez créer il suffit souvent de cocher une case), et il est également beaucoup plus difficile à résoudre pour un scripteur qu'une simple image diffusée à partir de votre site.

• N'incluez pas la solution pour le captcha dans le balisage HTML: j'ai en fait vu un site Web qui contenait la solution pour le captcha dans la page elle-même (bien que très bien cachée). ) le rendant ainsi assez inutile. Ne fais pas quelque chose comme ça. Encore une fois, utilisez un service comme reCaptcha, et vous n'aurez pas ce genre de problème (si vous l'utilisez correctement).

• Les captchas peuvent être résolus en bloc: Il existe des services de résolution de captcha où des humains réels, faiblement rémunérés, résolvent les captchas en bloc. Encore une fois, utiliser reCaptcha est une bonne idée ici, car ils disposent de protections (telles que le temps relativement court dont dispose l'utilisateur pour résoudre le captcha). Il est peu probable que ce type de service soit utilisé à moins que vos données ne soient vraiment utiles.

Servez votre contenu textuel sous forme d'image

Vous pouvez restituer du texte dans une image côté serveur et l'utiliser, ce qui gênera l'extraction de texte par de simples scrapers.

Cependant, c'est mauvais pour les lecteurs d'écran, les moteurs de recherche, les performances et à peu près tout le reste. C'est également illégal à certains endroits (en raison de l'accessibilité, par exemple la Loi sur les Américains handicapés), et il est également facile de le contourner avec certains OCR, alors ne le faites pas.

Vous pouvez faire quelque chose de similaire avec les sprites CSS, mais avec les mêmes problèmes.

N'exposez pas votre jeu de données complet:

Si possible, ne fournissez pas à un script/bot un moyen d'obtenir l'ensemble de votre jeu de données. Par exemple: vous avez un site de nouvelles, avec beaucoup d'articles individuels. Vous pouvez faire en sorte que ces articles soient uniquement accessibles en les recherchant via la recherche sur site, et, si vous ne possédez pas de liste , tous les articles du site et leurs URL. n'importe où, ces articles ne seront accessibles qu'en utilisant la fonction de recherche. Cela signifie qu'un script souhaitant extraire tous les articles de votre site devra rechercher toutes les expressions possibles pouvant apparaître dans vos articles afin de les retrouver toutes, ce qui prendra du temps, sera terriblement inefficace et, espérons-le, fera le racloir abandonne.

Ce sera inefficace si:

• Le bot/script ne veut pas/n'a pas besoin de l'intégralité du jeu de données.
• Vos articles sont servis à partir d'une URL qui ressemble à quelque chose comme example.com/article.php?articleId=12345. Ceci (et des choses similaires) qui permettra aux grattoirs de simplement parcourir tous les articleIds et de demander tous les articles de cette façon.
• Il existe d'autres moyens de rechercher tous les articles, par exemple en écrivant un script pour suivre les liens contenus dans des articles menant à d'autres articles.
• Rechercher quelque chose comme "et" ou "le" peut révéler presque tout, alors il faut en prendre conscience. (Vous pouvez éviter cela en ne renvoyant que les 10 ou 20 premiers résultats).
• Vous avez besoin de moteurs de recherche pour trouver votre contenu.

N'exposez pas vos API, points de terminaison et autres choses similaires:

Assurez-vous de ne pas exposer les API, même involontairement. Par exemple, si vous utilisez AJAX ou des requêtes réseau à partir d'Adobe Flash ou Java Applets (Dieu nous en préserve!) Pour charger vos données, il est trivial de consulter les requêtes réseau du page et déterminez où vont ces demandes, puis effectuez un reverse engineering et utilisez ces points de terminaison dans un programme scraper. Veillez à masquer vos points de terminaison et à les rendre difficiles à utiliser, comme décrit.

Pour dissuader les analyseurs et les scrapers HTML:

Puisque les analyseurs HTML travaillent en extrayant le contenu de pages à partir de modèles identifiables dans le code HTML, nous pouvons intentionnellement modifier ces modèles afin de casser ces scraper ou même de les visionner. La plupart de ces conseils s'appliquent également à d'autres grattoirs, comme les araignées et les écrans.

Changez fréquemment votre HTML

Les nettoyeurs qui traitent directement le HTML le font en extrayant le contenu de parties spécifiques et identifiables de votre page HTML. Par exemple: si toutes les pages de votre site Web ont un div avec un identifiant de article-content, qui contient le texte de l'article, il est alors trivial d'écrire un script pour visiter toutes les pages de votre article. site et extrayez le texte du contenu de article-content div sur chaque page d'article, et voilà, le grattoir contient tous les articles de votre site dans un format pouvant être réutilisé ailleurs.

Si vous modifiez fréquemment le code HTML et la structure de vos pages, ces scrapers ne fonctionneront plus.

• Vous pouvez fréquemment modifier les identifiants et les classes d'éléments dans votre code HTML, peut-être même automatiquement. Donc, si votre div.article-content devient quelque chose comme div.a4c36dda13eaf0 et change toutes les semaines, le racloir fonctionnera correctement au départ, mais se rompra au bout d'une semaine. Veillez également à modifier la longueur de vos identifiants/classes, sinon le racleur utilisera div.[any-14-characters] pour rechercher le div souhaité. Méfiez-vous des autres trous similaires aussi ..

• S'il n'y a aucun moyen de trouver le contenu souhaité à partir du balisage, le scraper le fera de la manière dont le code HTML est structuré. Donc, si toutes les pages de vos articles sont similaires, chaque div à l'intérieur d'un div suivant un h1 est le contenu de l'article, les scrapeurs obtiendront le contenu de l'article sur cette base. Encore une fois, pour rompre cela, vous pouvez ajouter/supprimer des balises supplémentaires à votre code HTML, périodiquement et de manière aléatoire, par exemple. ajout de divs ou spans supplémentaire. Avec le traitement HTML côté serveur moderne, cela ne devrait pas être trop difficile.

Ce qu'il faut savoir:

• Ce sera fastidieux et difficile à implémenter, maintenir et déboguer.

• Vous empêcherez la mise en cache. En particulier, si vous modifiez les identifiants ou les classes de vos éléments HTML, cela nécessitera des modifications correspondantes dans vos fichiers CSS et JavaScript, ce qui signifie que chaque fois que vous les modifierez, ils devront être re-téléchargés par le navigateur. Cela se traduira par des temps de chargement de page plus longs pour les visiteurs assidus et une charge de serveur accrue. Si vous ne le changez qu'une fois par semaine, ce ne sera pas un gros problème.

• Les racleurs intelligents pourront toujours obtenir votre contenu en déduisant où se trouve le contenu réel, par exemple. en sachant qu'un seul grand bloc de texte sur la page est susceptible d'être l'article lui-même. Cela permet de toujours trouver et extraire les données souhaitées de la page. Boilerpipe fait exactement cela.

Assurez-vous qu’un script ne trouve pas facilement le contenu souhaité pour chaque page similaire.

Voir aussi Comment empêcher les robots d'exploration basés sur XPath d'obtenir le contenu de la page pour plus d'informations sur la façon dont cela peut être implémenté en PHP.

Modifier votre code HTML en fonction de l'emplacement de l'utilisateur

Ceci est en quelque sorte similaire au conseil précédent. Si vous utilisez un code HTML différent en fonction de la localisation/du pays de votre utilisateur (déterminé par son adresse IP), cela peut endommager les scrapers fournis aux utilisateurs. Par exemple, si quelqu'un est en train d'écrire une application mobile qui extrait des données de votre site, cela fonctionnera bien dans un premier temps, mais se cassera si elle est réellement distribuée aux utilisateurs, car ces utilisateurs peuvent se trouver dans un autre pays et obtenir ainsi un code HTML différent. grattoir intégré n'a pas été conçu pour consommer.

Changez fréquemment votre HTML, vissez activement les scrapers en le faisant!

Un exemple: votre site Web comporte une fonction de recherche, située à l'adresse example.com/search?query=somesearchquery, qui renvoie le code HTML suivant:

<div class="search-result">
  <h3 class="search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
  <p class="search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
  <a class"search-result-link" href="/stories/story-link">Read more</a>
</div>
(And so on, lots more identically structured divs with search results)

Comme vous l'avez peut-être deviné, il est facile de gratter: il suffit de cliquer sur l'URL de recherche avec une requête et d'extraire les données souhaitées du code HTML renvoyé. En plus de changer périodiquement le code HTML comme décrit ci-dessus, vous pouvez également conserver l'ancien balisage avec les anciens identifiants et classes, le masquer avec CSS et le remplir avec de fausses données, empoisonnant ainsi le racleur. Voici comment modifier la page de résultats de recherche:

<div class="the-real-search-result">
  <h3 class="the-real-search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
  <p class="the-real-search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
  <a class"the-real-search-result-link" href="/stories/story-link">Read more</a>
</div>

<div class="search-result" style="display:none">
  <h3 class="search-result-title">Visit Example.com now, for all the latest Stack Overflow related news !</h3>
  <p class="search-result-excerpt">Example.com is so awesome, visit now !</p>
  <a class"search-result-link" href="http://example.com/">Visit Now !</a>
</div>
(More real search results follow)

Cela signifie que les scrapeurs écrits pour extraire des données du code HTML basées sur des classes ou des identifiants continueront apparemment de fonctionner, mais ils obtiendront de fausses données ou même des annonces, des données que les vrais utilisateurs ne verront jamais, car ils sont masqués avec CSS.

Visser avec le grattoir: insérez de fausses données de honeypot invisibles dans votre page

En ajoutant à l'exemple précédent, vous pouvez ajouter des éléments de pot de miel invisibles à votre code HTML pour intercepter des scrapers. Un exemple qui pourrait être ajouté à la page de résultats de recherche décrite précédemment:

<div class="search-result" style="display:none">
  <h3 class="search-result-title">This search result is here to prevent scraping</h3>
  <p class="search-result-excerpt">If you're a human and see this, please ignore it. If you're a scraper, please click the link below :-)
  Note that clicking the link below will block access to this site for 24 hours.</p>
  <a class"search-result-link" href="/scrapertrap/scrapertrap.php">I'm a scraper !</a>
</div>
(The actual, real, search results follow.)

Un grattoir écrit pour obtenir tous les résultats de recherche le détectera, tout comme n'importe quel autre résultat, les résultats de recherche réels sur la page, et visitera le lien, à la recherche du contenu souhaité. Un vrai humain ne le verra jamais même en premier lieu (étant caché avec CSS), et ne visitera pas le lien. Une araignée authentique et désirable telle que celle de Google ne visitera pas le lien non plus parce que vous avez interdit /scrapertrap/ dans votre fichier robots.txt.

Vous pouvez demander à votre scrapertrap.php de bloquer l'accès à l'adresse IP qui l'a visité ou de forcer un captcha pour toutes les demandes ultérieures émanant de cette adresse IP.

• N'oubliez pas de refuser votre pot de miel (/scrapertrap/] dans votre fichier robots.txt afin que les robots des moteurs de recherche n'y tombent pas.

• Vous pouvez/devriez combiner ceci avec la précédente astuce consistant à changer fréquemment votre code HTML.

• Changez-le aussi souvent, car les grattoirs finiront par apprendre à l'éviter. Changez l'URL et le texte du pot de miel. Envisagez également de modifier le CSS en ligne utilisé pour le masquage et utilisez plutôt un attribut ID et un CSS externe, car les scrapeurs apprendront à éviter tout ce qui a un attribut style avec CSS utilisé pour masquer le contenu. Essayez également de ne l'activer que de temps en temps, de sorte que le racleur fonctionne au départ, mais se casse au bout d'un moment. Ceci s'applique également au conseil précédent.

• Les personnes mal intentionnées peuvent empêcher l'accès à de vrais utilisateurs en partageant un lien vers votre pot de miel, ou même en intégrant ce lien quelque part sous forme d'image (par exemple, sur un forum). Changez l'URL fréquemment et rendez les temps d'interdiction relativement courts.

Servir des données fausses et inutiles si vous détectez un grattoir

Si vous détectez ce qui est manifestement un grattoir, vous pouvez diffuser des données fausses et inutiles. cela corrompra les données que le racleur obtient de votre site Web. Vous devez également faire en sorte qu'il soit impossible de distinguer de telles fausses données de vraies données, de sorte que les grattoirs ne sachent pas qu'ils se font avoir.

Par exemple: vous avez un site de nouvelles; si vous détectez un racleur, au lieu de bloquer l'accès, vous distribuez de faux articles générés aléatoirement , ce qui empoisonnera les données qu'il obtiendra. Si vous faites que vos fausses données ne se distinguent pas de la réalité, les racleurs auront du mal à obtenir ce qu'ils veulent, à savoir les données réelles.

Ne pas accepter les demandes si l'agent utilisateur est vide/manquant

Souvent, les gratteurs mal rédigés n’enverront pas d’en-tête d’agent utilisateur avec leur demande, contrairement à tous les navigateurs, ainsi qu’aux robots de recherche.

Si vous recevez une demande dans laquelle l'en-tête de l'agent d'utilisateur n'est pas présent, vous pouvez afficher un captcha ou simplement bloquer ou limiter l'accès. (Ou servir de fausses données comme décrit ci-dessus, ou quelque chose d'autre ..)

Il est trivial de parodier, mais il vaut la peine d'être mis en œuvre pour lutter contre les grattoirs mal écrits.

N'acceptez pas les demandes si l'agent d'utilisateur est un utilisateur courant; les listes noires utilisées par les racleurs

Dans certains cas, les scrapeurs utiliseront un agent utilisateur qui n’est pas utilisé par un véritable navigateur ou un véritable moteur de recherche, tel que:

• "Mozilla" (rien que ça, rien d'autre. J'ai vu quelques questions à propos de gratter ici, en utilisant cela. Un vrai navigateur n'utilisera jamais seulement cela)
• "Java 1.7.43_u43" (Par défaut, HttpUrlConnection de Java utilise quelque chose comme ceci.)
• "BIZCO EasyScraping Studio 2.0"
• "wget", "curl", "libcurl", .. (Wget et cURL sont parfois utilisés pour le grattage de base)

Si vous constatez qu'une chaîne d'agent d'utilisateur spécifique est utilisée par les scrapers de votre site et qu'elle n'est pas utilisée par de vrais navigateurs ni par des araignées légitimes, vous pouvez également l'ajouter à votre liste noire.

S'il ne demande pas d'actifs (CSS, images), ce n'est pas un vrai navigateur.

Un vrai navigateur demandera (presque toujours) et téléchargera des ressources telles que des images et des CSS. Les analyseurs et les scrapers HTML ne le seront pas car ils ne sont intéressés que par les pages et leur contenu.

Vous pouvez consigner les demandes dans vos ressources et si vous voyez beaucoup de demandes portant uniquement sur le code HTML, il peut s’agir d’un racleur.

Attention, les robots des moteurs de recherche, les anciens appareils mobiles, les lecteurs d'écran et les appareils mal configurés ne peuvent pas non plus demander des actifs.

Utiliser et demander des cookies; utilisez-les pour suivre les actions de l'utilisateur et du racleur.

Vous pouvez exiger que les cookies soient activés pour afficher votre site Web. Cela dissuadera les rédacteurs novices et novices, mais il est facile pour un racleur d'envoyer des cookies. Si vous les utilisez et si vous en avez besoin, vous pouvez suivre les actions des utilisateurs et des utilisateurs, et ainsi mettre en œuvre la limitation de débit, le blocage ou l'affichage des captchas utilisateur par utilisateur plutôt que par IP.

Par exemple: lorsque l'utilisateur effectue une recherche, définissez un cookie d'identification unique. Lorsque les pages de résultats sont visualisées, vérifiez ce cookie. Si l'utilisateur ouvre tous les résultats de la recherche (vous pouvez le savoir à partir du cookie), c'est probablement un grattoir.

L'utilisation de cookies peut s'avérer inefficace, car les scrapers peuvent également envoyer les cookies avec leurs demandes et les supprimer si nécessaire. Vous empêcherez également l'accès aux vrais utilisateurs pour lesquels les cookies sont désactivés, si votre site fonctionne uniquement avec des cookies.

Notez que si vous utilisez JavaScript pour définir et récupérer le cookie, vous bloquez les scrapers qui n'exécutent pas JavaScript, car ils ne peuvent pas récupérer et envoyer le cookie avec leur demande.

Utilisez JavaScript + Ajax pour charger votre contenu

Vous pouvez utiliser JavaScript + AJAX pour charger votre contenu une fois la page chargée. Cela rendra le contenu inaccessible aux analyseurs HTML qui n'exécutent pas JavaScript. C'est souvent un moyen de dissuasion efficace pour les programmeurs débutants et inexpérimentés écrivant des scrapers.

Soyez conscient de:

• Utiliser JavaScript pour charger le contenu réel dégradera l'expérience et les performances de l'utilisateur

• Les moteurs de recherche peuvent ne pas utiliser JavaScript non plus, les empêchant ainsi d'indexer votre contenu. Cela peut ne pas poser de problème pour les pages de résultats de recherche, mais pour d’autres choses, telles que les pages d’article.

Brouiller votre balisage, les requêtes réseau à partir de scripts et tout le reste.

Si vous utilisez Ajax et JavaScript pour charger vos données, masquer les données transférées. Par exemple, vous pouvez coder vos données sur le serveur (avec quelque chose d'aussi simple que base64 ou plus complexe), puis les décoder et les afficher sur le client, après avoir été récupérées via Ajax. Cela signifie qu'une personne inspectant le trafic réseau ne verra pas immédiatement le fonctionnement de votre page et chargera des données, et il sera plus difficile pour une personne de demander directement des données de demande à vos points finaux, car elle devra procéder à un reverse engineering de votre algorithme de désembrouillage.

• Si vous utilisez Ajax pour charger les données, vous devez rendre difficile l’utilisation des points de terminaison sans charger la page au préalable, par exemple en demandant une clé de session en tant que paramètre, que vous pouvez intégrer dans votre code JavaScript ou HTML.

• Vous pouvez également incorporer vos données masquées directement dans la page HTML initiale et utiliser JavaScript pour les désobfusquer et les afficher, ce qui éviterait les requêtes réseau supplémentaires. Cela rendra beaucoup plus difficile l'extraction des données à l'aide d'un analyseur syntaxique HTML qui ne fait pas appel à JavaScript, car celui qui écrit doit utiliser un reverse engineering de JavaScript (que vous devez également masquer).

• Vous voudrez peut-être changer vos méthodes d'obfuscation régulièrement, pour casser les grattoirs qui l'ont découvert.

Cependant, il y a plusieurs inconvénients à faire quelque chose comme ceci:

• Ce sera fastidieux et difficile à implémenter, maintenir et déboguer.

• Il sera inefficace contre les scrapers et les screenscrapers qui exécutent JavaScript et extraient ensuite les données. (La plupart des analyseurs HTML simples n'exécutent pas JavaScript cependant)

• Si votre JavaScript est désactivé, cela rendra votre site non fonctionnel pour les utilisateurs réels.

• Les performances et les temps de chargement des pages en souffriront.

Non technique:

• Dites aux gens de ne pas gratter, et certains le respecteront

• Trouver un avocat

• Rendez vos données disponibles, fournissez une API:

  Vous pouvez rendre vos données facilement disponibles et demander une attribution et un lien vers votre site. Peut-être facturer $$$ pour cela.

Divers:

• Il existe également des services commerciaux de protection contre le raclage, tels que l'anti-raclage par Cloudflare ou Distill Networks (Détails sur son fonctionnement ici ), qui font ces choses, et bien plus encore. toi.

• Trouvez un équilibre entre convivialité pour de vrais utilisateurs et sécurité: tout ce que vous ferez aura un impact négatif sur l'expérience utilisateur, d'une manière ou d'une autre, et vous permettra de trouver des compromis.

• N'oubliez pas votre site mobile et vos applications. Si vous disposez d'une application mobile, celle-ci peut également être capturée à l'écran et le trafic réseau peut être inspecté pour déterminer les points d'extrémité REST qu'elle utilise.

• Les racleurs peuvent gratter d’autres racleurs: s’il existe un site Web dont le contenu a été gratté, les autres racleurs peuvent également extraire du site Web de ce racleur.

Lectures complémentaires:

• article de Wikipedia sur le Web grattant . Nombreux détails sur les technologies utilisées et les différents types de racleur Web.

• Empêche les scripteurs de claquer votre site Web des centaines de fois par seconde . Questions-réponses sur un problème très similaire: les robots consultent un site Web et achètent des produits dès leur mise en vente. Beaucoup d'informations pertinentes, en particulier sur les captchas et limitant le débit.

Answer 2

Je présume que vous avez configuré robots.txt.

Comme d'autres l'ont mentionné, les grattoirs peuvent simuler presque tous les aspects de leurs activités, et il est probablement très difficile d'identifier les demandes émanant des méchants.

Je considérerais:

1. Configurez une page, /jail.html.
2. Désactivez l'accès à la page dans robots.txt (afin que les araignées respectueuses ne visitent jamais).
3. Placez un lien sur l'une de vos pages, en le masquant avec CSS (display: none).
4. Enregistrer les adresses IP des visiteurs de /jail.html.

Cela pourrait vous aider à identifier rapidement les demandes des grattoirs qui ignorent de manière flagrante votre robots.txt.

Vous voudrez peut-être aussi faire de votre /jail.html un site Web complet doté du même balisage exact que les pages normales, mais contenant de fausses données (/jail/album/63ajdka, /jail/track/3aads8, etc.). De cette façon, les mauvais racleurs ne seront pas alertés par une "entrée inhabituelle" jusqu'à ce que vous ayez la possibilité de les bloquer complètement.

Answer 3

Sue 'em.

Sérieusement: si vous avez un peu d'argent, parlez-en à un bon jeune avocat gentil qui sait se débrouiller avec les Internets. Vous pourriez vraiment être capable de faire quelque chose ici. En fonction de l'emplacement des sites, vous pouvez demander à un avocat de rédiger un cesser et de s'abstenir ou son équivalent dans votre pays. Vous pourrez peut-être au moins effrayer les bâtards.

Documentez l'insertion de vos valeurs factices. Insérez des valeurs factices qui vous indiquent clairement (mais de manière obscure). Je pense que c'est une pratique courante chez les entreprises de vente d'annuaires téléphoniques, et ici en Allemagne, je pense qu'il y a eu plusieurs cas où des imitateurs se sont fait avoir par de fausses entrées qu'ils ont copiées 1: 1.

Il serait dommage que cela vous pousse à modifier votre code HTML, à faire glisser le référencement, la validité, etc. (même si un système de templates utilisant une structure HTML légèrement différente à chaque requête pour des pages identiques peut déjà aider une - lot contre les scrapeurs qui utilisent toujours des structures HTML et des noms de classe/ID pour extraire le contenu.)

Des cas comme celui-ci sont pour quoi les lois sur le droit d'auteur sont bonnes. Vous devriez pouvoir vous battre contre le travail honnête des autres pour gagner de l'argent.

Answer 4

Vous ne pouvez vraiment rien faire pour empêcher cela complètement. Les racleurs peuvent simuler leur agent utilisateur, utiliser plusieurs adresses IP, etc. et apparaître comme un utilisateur normal. La seule chose que vous pouvez faire est de rendre le texte non disponible au moment du chargement de la page: créez-le avec une image, flashz ou chargez-le avec JavaScript. Cependant, les deux premières idées sont mauvaises et la dernière serait un problème d'accessibilité si JavaScript n'est pas activé pour certains de vos utilisateurs habituels.

S'ils claquent absolument votre site et parcourent toutes vos pages, vous pouvez limiter le débit.

Il y a un peu d'espoir cependant. Les racleurs s'appuient sur un format cohérent des données de votre site. Si vous pouviez le rendre aléatoire, cela pourrait briser leur grattoir. Des choses comme changer l'ID ou les noms de classe des éléments de page sur chaque chargement, etc. Mais c'est beaucoup de travail à faire et je ne suis pas sûr que cela en vaille la peine. Et même alors, ils pourraient probablement contourner le problème avec suffisamment de dévouement.

Answer 5

Fournissez une API XML pour accéder à vos données. de manière simple à utiliser. Si les gens veulent vos données, ils les auront, vous pourriez aussi bien tout mettre en œuvre.

De cette façon, vous pouvez fournir un sous-ensemble de fonctionnalités de manière efficace, en veillant à ce que, au minimum, les scrapeurs ne gênent pas les requêtes HTTP et les quantités massives de bande passante.

Il ne vous reste plus qu'à convaincre les personnes qui souhaitent que vos données utilisent l'API. ;)

Answer 6

Désolé, c'est vraiment très difficile de faire ça ...

Je vous suggérerais de leur demander poliment de ne pas utiliser votre contenu (si votre contenu est protégé par des droits d'auteur).

Si c'est le cas et qu'ils ne l'enlèvent pas, vous pouvez alors prendre des mesures supplémentaires et leur envoyer une lettre de cessation et d'abandon .

En règle générale, quoi que vous fassiez pour éviter les éraflures aura probablement un effet plus négatif, par exemple. accessibilité, robots/araignées, etc.

Answer 7

Comme le disent tous les posts, si vous voulez que le moteur de recherche soit convivial, les bots peuvent gratter à coup sûr.

Mais vous pouvez toujours faire quelques choses, et cela peut avoir un impact sur 60 à 70% des robots.

Faites un script de vérificateur comme ci-dessous.

Si une adresse IP particulière visite très rapidement, après quelques visites (5 à 10), mettez son adresse IP + les informations de son navigateur dans un fichier ou une base de données.

La prochaine étape

(Il s’agirait d’un processus en arrière-plan exécuté à tout moment ou planifié au bout de quelques minutes.) Créez un autre script qui continuera de vérifier les adresses IP suspectes.

Cas 1. Si l'agent utilisateur appartient à un moteur de recherche connu tel que Google, Bing , Yahoo (vous pouvez trouver plus d'informations sur les agents utilisateurs en le recherchant sur Google). Ensuite, vous devez voir http://www.iplists.com/ . Cette liste et essayez de faire correspondre les modèles. Et si cela ressemble à un faux agent utilisateur, demandez à remplir un CAPTCHA lors de la prochaine visite. (Vous devez rechercher un peu plus sur les adresses IP des bots. Je sais que cela est réalisable et essayez également le whois de l'adresse IP. Cela peut être utile.)

Cas 2. Aucun agent utilisateur d’un robot de recherche: Il vous suffit de demander à remplir un CAPTCHA lors de la prochaine visite.

Answer 8

Réponse tardive - et cette réponse n’est probablement pas celle que vous voulez entendre ...

Moi-même ai déjà écrit de nombreux (plusieurs dizaines) de différents spécialisés grattoirs d'extraction de données. (juste parce que j'aime la philosophie des "données ouvertes").

Voici déjà de nombreux conseils dans d'autres réponses - . Je vais maintenant jouer le rôle de défenseur du diable et étendre et/ou corriger leur efficacité.

Première:

• si quelqu'un veut vraiment connaître vos données
• vous ne pouvez pas efficacement (techniquement) cacher vos données
• si les données doivent être accessibles publiquement à vos "utilisateurs réguliers"

Essayer d'utiliser des barrières techniques ne vaut pas la peine, à cause de:

• à vos utilisateurs réguliers en aggravant leur expérience utilisateur
• aux robots réguliers et bien accueillis (moteurs de recherche)
• etc...

Plain HMTL - Le moyen le plus simple est d'analyser les pages HTML simples, avec une structure bien définie et des classes css. Par exemple. il suffit d’inspecter un élément avec Firebug et d’utiliser le bon chemin Xpath et/ou CSS dans mon racleur.

Vous pouvez générer la structure HTML de manière dynamique et également, de manière dynamique, les noms de classe CSS (ainsi que le CSS lui-même) (par exemple, en utilisant des noms de classe aléatoires) - mais

• vous souhaitez présenter les informations à vos utilisateurs réguliers de manière cohérente
• par exemple. encore une fois - il suffit d'analyser une nouvelle fois la structure de la page pour configurer le racleur.
• et cela peut être fait automatiquement en analysant du "contenu déjà connu"
  • une fois que quelqu'un le sait déjà (par exemple), par exemple:
  • ce qui contient les informations sur "phil collins"
  • assez afficher la page "phil collins" et analyser (automatiquement) comment la page est structurée "aujourd'hui" :)

Vous ne pouvez pas changer la structure pour chaque réponse, car vos utilisateurs habituels vont vous détester. En outre, cela causera plus de problèmes pour vous (maintenance), pas pour le racleur. Le chemin XPath ou CSS peut être déterminé par le script de grattage automatiquement à partir du contenu connu.

Ajax - un peu plus difficile au début, mais accélère souvent le processus de grattage :) - pourquoi?

Lors de l'analyse des demandes et des réponses, je viens de configurer mon propre serveur proxy (écrit en Perl) et mon firefox l'utilise. Bien sûr, comme il s’agit de mon propre proxy - il est complètement masqué - le serveur cible le voit comme un navigateur classique. (Donc, aucun en-tête X-Forwarded-for et autres). Sur la base des journaux de proxy, il est généralement possible de déterminer la "logique" des demandes ajax, par ex. Je pourrais ignorer la plupart des opérations de grattage html et utiliser simplement les réponses ajax bien structurées (principalement au format JSON).

Donc, le ajax n'aide pas beaucoup ...

Quelques pages plus compliquées sont des pages qui utilisent beaucoup des fonctions JavaScript remplies .

Il est possible d’utiliser deux méthodes de base:

• décompressez et comprenez le JS et créez un grattoir qui suit la logique Javascript (à la dure)
• ou (de préférence par moi-même) - juste en utilisant Mozilla avec Mozrepl pour gratter. Par exemple. le véritable balayage s'effectue dans un navigateur doté de javascript complet, programmé pour cliquer sur les bons éléments et récupérer les réponses "décodées" directement à partir de la fenêtre du navigateur.

Ce raclage est lent (le raclage se fait comme dans un navigateur classique), mais il est

• très facile à installer et à utiliser
• et il est presque impossible de le contrer :)
• et la "lenteur" est quand même nécessaire pour contrer le "blocage des mêmes requêtes rapides basées sur IP"

Le filtrage basé sur User-Agent n'aide en rien. Tout chercheur de données sérieux le réglera correctement dans son grattoir.

Exiger une connexion - n'aide pas. Le moyen le plus simple de le battre (sans aucune analyse et/ou script du protocole de connexion) est simplement de se connecter au site en tant qu'utilisateur ordinaire, en utilisant Mozilla et après avoir exécuté le scraper basé sur Mozrepl ...

Rappelez-vous, le nécessite une connexion aide les bots anonymes, mais pas contre quelqu'un qui veut effacer vos données. Il vient de s'inscrire sur votre site en tant qu'utilisateur régulier.

L'utilisation de cadres n'est pas très efficace également. Ceci est utilisé par de nombreux services de films en direct et ce n'est pas très difficile à battre. Les cadres sont simplement des pages HTML/Javascript, ce qui est nécessaire pour analyser ... Si les données valent la peine - le ministe effectuera l'analyse requise.

La limitation basée sur IP n'est pas du tout efficace - il y a trop de serveurs proxy publics et voici aussi le mandat ... :) Cela ne marche pas t ralentit le raclage (pour quelqu'un qui veut vraiment vos données).

Il est très difficile de supprimer les données cachées dans les images. (par exemple, convertir simplement les données en images côté serveur). L'utilisation de "tesseract" (OCR) aide plusieurs fois - mais honnêtement - les données doivent valoir la peine pour le racleur. (ce qui souvent ne vaut pas la peine).

De l'autre côté, vos utilisateurs vont vous détester pour cela. Moi-même (même quand je ne gratte pas), je déteste les sites Web qui ne permettent pas de copier le contenu de la page dans le presse-papiers (car les informations sont contenues dans les images, ou (les plus idiots) essayant de créer un lien avec un clic droit sur un événement Javascript personnalisé: )

Les plus difficiles sont les sites utilisant des applets Java ou flash , et l’applet utilise secure https se demande en interne . Mais réfléchissez-y à deux fois - à quel point vos utilisateurs d’iPhone seront heureux…;). Par conséquent, actuellement, très peu de sites les utilisent. Moi-même, je bloque tout le contenu Flash dans mon navigateur (lors de sessions de navigation normales) - et je n'utilise jamais de sites qui dépendent de Flash.

Vos jalons pourraient être ..., alors vous pouvez essayer cette méthode - mais n'oubliez pas - vous allez probablement perdre certains de vos utilisateurs. Rappelez-vous également que certains fichiers SWF sont décompilables. ;)

Captcha (les bons - comme reCaptcha) aide beaucoup - mais vos utilisateurs vont vous détester ... - imaginez comment vos utilisateurs vont vous aimer quand ils ont besoin de résoudre des captchas dans toutes les pages montrant des informations sur les artistes de la musique.

Vous n'avez probablement pas besoin de continuer - vous êtes déjà entré dans l'image.

Maintenant ce que vous devriez faire:

N'oubliez pas: il est presque impossible de cacher vos données si vous voulez les publier (de manière conviviale) pour vos utilisateurs habituels.

Alors,

• rendre vos données facilement accessibles - par certaines API
  • cela permet un accès facile aux données
  • par exemple. Déchargez votre serveur de gratter - bon pour vous
• configurer les droits d'utilisation appropriés (par exemple, il faut citer la source)
• rappelez-vous que de nombreuses données ne sont pas protégées par le droit d'auteur et qu'il est difficile de les protéger
• ajoutez de fausses données (comme vous l'avez déjà fait) et utilisez des outils juridiques
  • comme d'autres l'ont déjà dit, envoyez une "lettre de cesser et de s'abstenir"
  • d'autres actions en justice (en justice et similaires) sont probablement trop coûteuses et difficiles à gagner (surtout contre des sites non américains)

Réfléchissez à deux fois avant d'essayer d'utiliser des barrières techniques.

Plutôt que d'essayer de bloquer les mineurs de données, ajoutez simplement plus d'efforts à la convivialité de votre site Web. Votre utilisateur va vous aimer. Le temps (et l'énergie) investis dans les barrières techniques ne vaut généralement pas la peine - il vaut mieux passer son temps à créer un site Web encore meilleur ...

En outre, les voleurs de données ne sont pas comme des voleurs normaux.

Si vous achetez une alarme à la maison peu coûteuse et ajoutez un avertissement "cette maison est reliée à la police" - de nombreux voleurs n'essaieront même pas d'entrer par effraction. Parce qu'un mauvais geste de sa part - et il va en prison ...

Donc, vous investissez seulement quelques dollars, mais le voleur investit et risque beaucoup.

Mais le voleur de données n'a pas de tels risques. Au contraire, si vous faites un faux mouvement (par exemple, si vous introduisez un bogue en raison d'obstacles techniques), vous perdrez vos utilisateurs. Si le robot de nettoyage ne fonctionne pas pour la première fois, rien ne se passe: l'exploitant de données essaiera simplement une autre approche et/ou déboguera le script.

Dans ce cas, vous avez besoin d'investir beaucoup plus - et le racleur d'investir beaucoup moins.

Pensez simplement où vous voulez investir votre temps et votre énergie ...

Ps: l'anglais n'est pas mon natif - alors pardonnez mon anglais cassé ...

Answer 9

Ce qui pourrait marcher contre les scrapers débutants:

• Blocage d'IP
• utiliser beaucoup d'ajax
• vérifier l'en-tête de demande de référent
• nécessite un login

Choses qui aideront en général:

• changez votre mise en page chaque semaine
• robots.txt

Les choses qui aideront mais feront que vos utilisateurs vous détestent:

• captcha

Answer 10

J'ai fait beaucoup de recherches sur le Web et en ai résumé quelques techniques permettant d’arrêter les scrapers sur mon blog en fonction de ce que je trouve ennuyeux.

C'est un compromis entre vos utilisateurs et vos scrapers. Si vous limitez les adresses IP, utilisez les CAPTCHA, avez besoin d'un identifiant de connexion, etc., vous faites comme difficile pour les grattoirs. Mais cela peut aussi faire fuir vos véritables utilisateurs.

Answer 11

D'un point de vue technique: il vous suffit de modéliser ce que Google fait lorsque vous lui soumettez trop de requêtes à la fois. Cela devrait mettre fin à beaucoup de choses.

D'un point de vue juridique: il semble que les données que vous publiez ne soient pas propriétaires. Cela signifie que vous publiez des noms, des statistiques et d'autres informations qui ne peuvent pas être protégées par des droits d'auteur.

Si tel est le cas, les scrapers ne violent pas le droit d'auteur en redistribuant vos informations sur le nom de l'artiste, etc. Cependant, ils peuvent également violer le droit d'auteur lorsqu'ils chargent votre site en mémoire car votre site contient des éléments protégés par le droit d'auteur (comme une mise en page, etc.).

Je recommande de lire à propos de Facebook v. Power.com et de voir les arguments que Facebook utilisait pour arrêter le grattage d'écran. Il existe de nombreuses manières légales de tenter d'empêcher quelqu'un de supprimer votre site Web. Ils peuvent être ambitieux et imaginatifs. Parfois, les tribunaux achètent les arguments. Parfois, ils ne le font pas.

Mais en supposant que vous publiez des informations du domaine public qui ne sont pas protégées par le droit d'auteur, comme les noms et les statistiques de base, laissez-les simplement aller au nom de la liberté d'expression et des données ouvertes. C'est ce que le Web est tout au sujet.

Answer 12

Malheureusement, votre meilleure option est assez manuelle: recherchez des schémas de trafic qui, à votre avis, indiquent un effacement et interdisez leurs adresses IP.

Étant donné que vous parlez d'un site public, rendre le site convivial pour les moteurs de recherche le rendra également convivial. Si un moteur de recherche peut explorer et gratter votre site, un scraper malveillant peut également le faire. C'est une ligne fine pour marcher.

Answer 13

Bien sûr que c'est possible. Pour un succès total, mettez votre site hors ligne.

En réalité, vous pouvez faire certaines des choses qui rendent le raclage un peu plus difficile. Google vérifie votre navigateur pour vous assurer que vous n'êtes pas un robot en train de gratter les résultats de la recherche (bien que cela puisse être usurpé, comme presque tout le reste).

Vous pouvez faire des choses telles que demander plusieurs secondes entre la première connexion à votre site et les clics ultérieurs. Je ne suis pas sûr du temps idéal ni de la manière exacte de le faire, mais c'est une autre idée.

Je suis sûr qu'il y a plusieurs autres personnes qui ont beaucoup plus d'expérience, mais j'espère que ces idées sont au moins quelque peu utiles.

Answer 14

1. Non, il n'est pas possible de s'arrêter (en aucune façon)
2. Embrasse le. Pourquoi ne pas publier en tant que RDFa et devenir un super moteur de recherche convivial et encourager la réutilisation des données? Les gens vous remercieront et vous donneront crédit, le cas échéant (voir musicbrainz à titre d'exemple).

Ce n'est pas la réponse que vous voulez probablement, mais pourquoi cacher ce que vous essayez de rendre public?

Answer 15

Vous pouvez faire plusieurs choses pour éviter de rayer l'écran. Certains ne sont pas très efficaces, alors que d'autres (un CAPTCHA) le sont, mais gênent la facilité d'utilisation. Vous devez également garder à l’esprit que cela peut entraver les opérations de grattage légitimes des sites, tels que les index des moteurs de recherche.

Cependant, je suppose que si vous ne le voulez pas, cela signifie que vous ne voulez pas non plus que les moteurs de recherche l'indexent.

Voici quelques choses que vous pouvez essayer:

• Afficher le texte dans une image. Ceci est assez fiable et pose moins de problèmes à l'utilisateur qu'un CAPTCHA, mais signifie qu'ils ne pourront pas couper et coller, ni être joliment redimensionné ou accessible.
• Utilisez un CAPTCHA et demandez-lui de le compléter avant de retourner la page. C’est une méthode fiable, mais aussi la plus grande peine à imposer à un utilisateur.
• Demander à l'utilisateur de créer un compte avant de visualiser les pages et de confirmer son adresse électronique. Ce sera assez efficace, mais pas tout à fait - un grattoir pourrait créer un compte et programmer intelligemment son script pour se connecter.
• Si la chaîne d'agent utilisateur du client est vide, bloquez l'accès. Un script de suppression de site sera souvent programmé paresseusement et ne définira pas de chaîne d'agent utilisateur, contrairement à tous les navigateurs Web.
• Vous pouvez définir une liste noire de chaînes d’agent d’utilisateur/utilisateur d’extracteur d’écran connues à mesure que vous les découvrez. Encore une fois, cela n’aidera que les codés paresseusement; un programmeur qui sait ce qu'il fait peut définir une chaîne d'agent utilisateur pour imiter un navigateur Web.
• Changer le chemin de l'URL souvent. Lorsque vous le modifiez, assurez-vous que l'ancien continue à fonctionner, mais uniquement tant qu'un utilisateur est susceptible de voir son navigateur ouvert. Difficile de prédire quel sera le nouveau chemin d’URL. Cela compliquera la tâche des scripts si leur URL est codée en dur. Il serait préférable de faire cela avec une sorte de script.

Si je devais le faire, j'utiliserais probablement une combinaison des trois derniers, car ils minimisent les inconvénients pour les utilisateurs légitimes. Cependant, vous devez accepter le fait que vous ne pourrez pas bloquer tout le monde de cette façon. Une fois que quelqu'un aura compris comment le contourner, il sera en mesure de le résoudre à tout jamais. Vous pouvez alors simplement essayer de bloquer leurs adresses IP lorsque vous les découvrez, je suppose.

Answer 16

Première méthode (petits sites uniquement):
Servir des données cryptées/encodées.
Scape le Web à l’aide de python (urllib, requêtes, beautifulSoup, etc.) et a trouvé de nombreux sites Web contenant des données chiffrées/codées qui ne peuvent être déchiffrées dans aucun langage de programmation simplement parce que la méthode de cryptage n'existe pas.

J'ai réalisé ceci dans un site Web PHP en chiffrant et en minimisant la sortie (ATTENTION: ceci n'est pas une bonne idée pour les sites volumineux), la réponse était toujours du contenu brouillé.

Exemple de réduction de la sortie dans PHP ( Comment réduire la sortie HTML d'une page php? ):

<?php
  function sanitize_output($buffer) {
    $search = array(
      '/\>[^\S ]+/s', // strip whitespaces after tags, except space
      '/[^\S ]+\</s', // strip whitespaces before tags, except space
      '/(\s)+/s'      // shorten multiple whitespace sequences
    );
    $replace = array('>', '<', '\\1');
    $buffer = preg_replace($search, $replace, $buffer);
    return $buffer;
  }
  ob_start("sanitize_output");
?>

Deuxième méthode:
Si vous ne pouvez pas les empêcher de les arrêter, envoyez-leur des réponses fausses ou inutiles.

Troisième méthode:
bloque les utilisateurs communs grattant, vous verrez cela dans les sites Web majeurs/grands, car il est impossible de les gratter avec "python3.4" en tant qu'agent utilisateur.

Méthode quatre:
Assurez-vous que tous les en-têtes d'utilisateurs sont valides. Je fournis parfois autant d'en-têtes que possible pour donner à mon racleur l'apparence d'un utilisateur authentique. Certains d'entre eux ne sont même pas vrais ou valables, comme en-FU :).
Voici une liste de certains des en-têtes que je fournis couramment.

headers = {
  "Requested-URI": "/example",
  "Request-Method": "GET",
  "Remote-IP-Address": "656.787.909.121",
  "Remote-IP-Port": "69696",
  "Protocol-version": "HTTP/1.1",
  "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
  "Accept-Encoding": "gzip,deflate",
  "Accept-Language": "en-FU,en;q=0.8",
  "Cache-Control": "max-age=0",
  "Connection": "keep-alive",
  "Dnt": "1",  
  "Host": "http://example.com",
  "Referer": "http://example.com",
  "Upgrade-Insecure-Requests": "1",
  "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"
}

Answer 17

Plutôt que de mettre des robots sur la liste noire, vous devriez peut-être les ajouter à la liste blanche. Si vous ne souhaitez pas supprimer les résultats de votre recherche pour les moteurs les plus performants, vous pouvez ajouter à la liste blanche leurs chaînes d’agent d’utilisateur, qui sont généralement bien connues. Les bots les moins éthiques ont tendance à créer des chaînes d’utilisateurs-agents sur les navigateurs Web populaires. Les quelques premiers moteurs de recherche devraient générer plus de 95% de votre trafic.

Identifier les robots eux-mêmes devrait être assez simple, en utilisant les techniques suggérées par d'autres afficheurs.

Answer 18

Une solution rapide à ce problème consisterait à définir un piège piège/bot.

1. Créez une page qui, si elle est ouverte un certain nombre de fois ou même du tout, collectera certaines informations, telles que l’adresse IP ou autre (vous pouvez également prendre en compte des irrégularités ou des motifs, mais cette page ne doit pas nécessairement être ouverte du tout).

2. Faites un lien vers cela dans votre page qui est masqué avec l'affichage CSS: aucun; ou à gauche: -9999px; position: absolue; essayez de le placer dans des endroits moins susceptibles d’être ignorés, comme votre contenu et non votre pied de page, car parfois les bots peuvent choisir d’oublier certaines parties de la page.

3. Dans votre fichier robots.txt, définissez toute une série de règles d'interdiction des pages sur lesquelles vous ne voulez pas de robots amis (LOL, comme si elles avaient des visages heureux!) Pour collecter des informations et définir cette page comme l'une d'entre elles.

4. Maintenant, si un bot ami arrive, il devrait ignorer cette page. Oui mais ça ne suffit toujours pas. Faites quelques pages de plus ou modifiez une page pour accepter des noms différents. et placez ensuite plus de règles d'interdiction pour ces pages d'interruption dans votre fichier robots.txt à côté des pages que vous souhaitez ignorer.

5. Rassemblez l’adresse IP de ces robots ou de tous ceux qui entrent dans ces pages, ne les bannissez pas, mais créez une fonction permettant d’afficher du texte noodled dans votre contenu, comme des nombres aléatoires, des mentions de copyright, des chaînes de texte spécifiques, des images effrayantes, bon contenu. Vous pouvez également définir des liens pointant vers une page dont le chargement, par exemple, prendra une éternité. en php, vous pouvez utiliser la fonction sleep (). Cela repoussera le robot d'exploration s'il dispose d'une sorte de détection pour ignorer les pages dont le chargement prend beaucoup trop de temps, car certains bots bien écrits sont configurés pour traiter X nombre de liens à la fois.

6. Si vous avez créé des chaînes de texte/phrases spécifiques, pourquoi ne pas aller dans votre moteur de recherche préféré et les rechercher, cela peut vous indiquer où se trouve votre contenu.

Quoi qu'il en soit, si vous pensez de manière tactique et créative, cela pourrait être un bon point de départ. La meilleure chose à faire serait d'apprendre comment fonctionne un bot.

Je penserais aussi à sabrer des identifiants ou la façon dont les attributs de l'élément de page sont affichés:

<a class="someclass" href="../xyz/abc" rel="nofollow" title="sometitle"> 

cela change sa forme à chaque fois car certains robots peuvent être configurés pour rechercher des modèles spécifiques dans vos pages ou des éléments ciblés.

<a title="sometitle" href="../xyz/abc" rel="nofollow" class="someclass"> 

id="p-12802" > id="p-00392"

Answer 19

Je suis d’accord avec la plupart des publications ci-dessus et j’aimerais ajouter que plus votre site est convivial pour les moteurs de recherche, plus il est susceptible d’être effacé. Vous pouvez essayer de faire plusieurs choses qui rendent les choses plus difficiles pour les scrapers, mais cela peut également affecter votre capacité de recherche ... Cela dépend de la façon dont vous souhaitez que votre site soit classé dans les moteurs de recherche.

Answer 20

La plupart ont déjà été dit, mais avez-vous envisagé la protection CloudFlare? Je veux dire ceci:

D'autres entreprises le font probablement aussi, CloudFlare est le seul que je connaisse.

Je suis sûr que cela compliquerait leur travail. Une fois, j’ai aussi été banni automatiquement pendant 4 mois lorsque j’ai essayé de supprimer les données d’un site protégé par CloudFlare en raison d’une limite de débit (j’utilisais une simple boucle de requête AJAX).

Answer 21

Vous ne pouvez pas arrêter le grattage normal de l'écran. Pour le meilleur ou pour le pire, c'est la nature du Web.

Vous pouvez faire en sorte que personne ne puisse accéder à certaines choses (y compris les fichiers de musique) à moins d'être connectés en tant qu'utilisateur enregistré. Ce n'est pas trop difficile à faire dans Apache . Je suppose que cela ne serait pas trop difficile à faire dans IIS.

Answer 22

Une solution serait de servir le contenu sous forme d'attributs XML, de chaînes codées par URL, de texte préformaté avec JSON codé en HTML ou d'URI de données, puis de le transformer en HTML sur le client. Voici quelques sites qui le font:

• Skechers : XML

  <document 
   filename="" 
   height="" 
   width="" 
   title="SKECHERS" 
   linkType="" 
   linkUrl="" 
   imageMap="" 
   href=&quot;http://www.bobsfromskechers.com&quot; 
   alt=&quot;BOBS from Skechers&quot; 
   title=&quot;BOBS from Skechers&quot; 
  />
  

• Chrome Web Store : JSON

  <script type="text/javascript" src="https://apis.google.com/js/plusone.js">{"lang": "en", "parsetags": "explicit"}</script>
  

• Bing News : URL de données

  <script type="text/javascript">
    //<![CDATA[
    (function()
      {
      var x;x=_ge('emb7');
      if(x)
        {
        x.src='data:image/jpeg;base64,/*...*/';
        } 
      }() )
  

• Protopage : Chaînes encodées par URL

  unescape('Rolling%20Stone%20%3a%20Rock%20and%20Roll%20Daily')
  

• TiddlyWiki : Entités HTML + JSON préformaté

     <pre>
     {&quot;tiddlers&quot;: 
      {
      &quot;GettingStarted&quot;: 
        {
        &quot;title&quot;: &quot;GettingStarted&quot;,
        &quot;text&quot;: &quot;Welcome to TiddlyWiki,
        }
      }
     }
     </pre>
  

• Amazon : Chargement paresseux

  amzn.copilot.jQuery=i;amzn.copilot.jQuery(document).ready(function(){d(b);f(c,function() {amzn.copilot.setup({serviceEndPoint:h.vipUrl,isContinuedSession:true})})})},f=function(i,h){var j=document.createElement("script");j.type="text/javascript";j.src=i;j.async=true;j.onload=h;a.appendChild(j)},d=function(h){var i=document.createElement("link");i.type="text/css";i.rel="stylesheet";i.href=h;a.appendChild(i)}})();
  amzn.copilot.checkCoPilotSession({jsUrl : 'http://z-ecx.images-Amazon.com/images/G/01/browser-scripts/cs-copilot-customer-js/cs-copilot-customer-js-min-1875890922._V1_.js', cssUrl : 'http://z-ecx.images-Amazon.com/images/G/01/browser-scripts/cs-copilot-customer-css/cs-copilot-customer-css-min-2367001420._V1_.css', vipUrl : 'https://copilot.Amazon.com'
  

• XMLCalabash : XML en espace de nom + Type MIME personnalisé + Extension de fichier personnalisée

     <p:declare-step type="pxp:Zip">
          <p:input port="source" sequence="true" primary="true"/>
          <p:input port="manifest"/>
          <p:output port="result"/>
          <p:option name="href" required="true" cx:type="xsd:anyURI"/>
          <p:option name="compression-method" cx:type="stored|deflated"/>
          <p:option name="compression-level" cx:type="smallest|fastest|default|huffman|none"/>
          <p:option name="command" select="'update'" cx:type="update|freshen|create|delete"/>
     </p:declare-step>
  

Si vous affichez la source sur l'un des éléments ci-dessus, vous constaterez que le grattage renvoie simplement des métadonnées et une navigation.

Answer 23

Les grattoirs fonctionnent en HTML. Et s'ils sont déterminés à obtenir vos données, vous ne pouvez pas faire beaucoup techniquement, car le globe oculaire humain traite quoi que ce soit. Légalement, il a déjà été signalé que vous pourriez avoir un recours, ce serait ma recommandation.

Cependant, vous pouvez masquer la partie critique de vos données en utilisant une logique de présentation non HTML.

• Générez un fichier Flash pour chaque artiste/album, etc.
• Générez une image pour chaque contenu d'artiste. Peut-être qu'une image pour le nom de l'artiste, etc. serait suffisante. Pour ce faire, restituez le texte dans un fichier JPEG / PNG sur le serveur et créez un lien vers cette image.

N'oubliez pas que cela affectera probablement votre classement dans les recherches.

Answer 24

Générez le HTML, CSS et JavaScript. Il est plus facile d'écrire des générateurs que des analyseurs, vous pouvez donc générer chaque page servie différemment. Vous ne pouvez plus utiliser de cache ni de contenu statique à ce moment-là.

Answer 25

Si vous voulez voir un bon exemple, consultez http://www.bkstr.com/ . Ils utilisent un algorithme j/s pour définir un cookie, puis rechargent la page afin qu'elle puisse utiliser le cookie pour valider que la demande est en cours d'exécution dans un navigateur. Une application de bureau conçue pour gratter pourrait certainement en venir à bout, mais elle empêcherait la plupart des grattages de type cURL.

Answer 26

Mettre votre contenu derrière un captcha signifierait que les robots auraient du mal à accéder à votre contenu. Cependant, les humains seraient incommodés, ce qui pourrait être indésirable.