Question

  

J'ai accepté une réponse, mais malheureusement, je pense que nous nous trouvons dans le pire scénario de départ: CAPTCHA pour les tentatives d'achat de la merde . Brève explication: la mise en cache / les fermes Web rendent impossible le suivi des hits, et toute solution de contournement (envoyer une balise Web non mise en cache, écrire sur une table unifiée, etc.) ralentit le site plus que ne le feraient les robots. Il existe probablement du matériel coûteux de Cisco ou similaire qui peut aider à un niveau élevé, mais il est difficile de justifier le coût si CAPTCHA-ing est une alternative. J'essaierai une explication plus complète plus tard, ainsi que de la nettoyer pour les futurs chercheurs (bien que d'autres personnes soient les bienvenues, car c'est le wiki de la communauté).

Situation

Il s’agit des ventes de sacs à main sur woot.com. Je suis le président de Woot Workshop, la filiale de Woot qui conçoit, écrit les descriptions de produits, les podcasts, les billets de blog et modère les forums. Je travaille avec CSS / HTML et je ne connais que très peu les autres technologies. Je travaille en étroite collaboration avec les développeurs et j'ai discuté de toutes les réponses ici (et de nombreuses autres idées que nous avons eues).

La convivialité fait partie intégrante de mon travail, et rendre le site plus excitant et amusant est la majeure partie du reste. C'est là que les trois objectifs ci-dessous dérivent. CAPTCHA nuit à la convivialité et les bots volent le plaisir et l’enthousiasme de nos ventes de merde.

Des robots claquent notre page d'accueil des dizaines de fois sur un deuxième écran en grattant (et / ou en balayant notre RSS) pour la vente au hasard. Au moment où ils voient cela, une deuxième étape du programme se déclenche: elle se connecte, clique sur Je veux un, remplit le formulaire et achète la merde.

Évaluation

  

lc : sur les sites stackoverflow et autres qui utilisent cette méthode, ils traitent presque toujours avec des utilisateurs authentifiés (connectés), car la tâche tentée le requiert.

Sur Woot, les utilisateurs anonymes (non connectés) peuvent consulter notre page d'accueil. En d’autres termes, les robots qui claquent peuvent être non authentifiés (et essentiellement non traçables, sauf par adresse IP).

Nous sommes donc de nouveau à la recherche d’adresses IP, ce qui a) est relativement inutile à l’ère des réseaux en nuage et des zombies spambots et b) surprend trop d’innocents compte tenu du nombre d’entreprises provenant d’une seule adresse IP (pour ne pas mentionner problèmes liés aux fournisseurs de services Internet IP non statiques et aux problèmes de performances potentiels pour tenter de le suivre).

Oh, et avoir des gens à nous appeler serait le pire scénario possible. Pouvons-nous qu'ils vous appellent?

  

BradC : les méthodes de Ned Batchelder sont plutôt cool, mais elles sont plutôt bien conçues pour vaincre les bots conçus pour un réseau de sites. Notre problème est que les robots sont construits spécifiquement pour vaincre notre site. Certaines de ces méthodes pourraient fonctionner pendant un court laps de temps, jusqu'à ce que les scripteurs fassent évoluer leurs robots pour ignorer le pot de miel, masquer l'écran pour les noms d'étiquettes proches au lieu des identifiants de formulaire et utiliser un contrôle de navigateur prenant en charge javascript.

& nbsp;

  

Encore une fois :" À moins que le battage publicitaire fasse partie de votre stratégie marketing. " Oui, c'est vraiment ça. La surprise du moment où le produit apparaît, de même que l'excitation que vous ressentez si vous parvenez à en obtenir un, sont probablement aussi importants ou plus importants que la merde que vous obtenez en fin de compte. Tout ce qui élimine le principe du premier arrivé / premier servi nuit au plaisir de «gagner» la merde.

& nbsp;

  

Était-ce utile?

La solution

Qu'en est-il de mettre en œuvre quelque chose comme SO fait avec les CAPTCHAs?

Si vous utilisez le site normalement, vous n'en verrez probablement jamais. S'il vous arrive de recharger trop souvent la même page, si vous postez des commentaires successifs trop rapidement ou si quelque chose d'autre déclenche une alarme, faites-leur prouver qu'ils sont humains. Dans votre cas, il s'agirait probablement de recharges constantes de la même page, suivies rapidement par chaque lien d'une page ou remplies trop rapidement un formulaire de commande pour être humain.

Si la vérification échoue x fois de suite (par exemple, 2 ou 3), accordez à cette adresse IP un délai d’expiration ou une autre mesure de ce type. Puis, à la fin du délai imparti, remettez-les à nouveau au contrôle.

Étant donné que des utilisateurs non enregistrés accèdent au site, vous ne pouvez utiliser que les adresses IP. Vous pouvez émettre des sessions sur chaque navigateur et effectuer ce suivi si vous le souhaitez. Et, bien sûr, lancez une vérification humaine si trop de sessions sont (re) créées successivement (au cas où un bot continuerait à supprimer le cookie).

Pour attraper trop d'innocents, vous pouvez afficher une clause de non-responsabilité sur la page de vérification des utilisateurs: "Cette page peut également apparaître si un trop grand nombre d'utilisateurs anonymes consultent notre site à partir du même emplacement. Nous vous encourageons à vous enregistrer ou à vous connecter pour éviter cela. & Quot; (Ajustez le libellé de manière appropriée.)

En outre, quelles sont les chances que X personnes chargent la même page (s) en même temps depuis une adresse IP? Si elles sont hautes, vous aurez peut-être besoin d'un mécanisme de déclenchement différent pour votre alarme bot.

Modifier: si vous échouez trop souvent et si vous êtes confiant quant à la demande du produit, vous pouvez les bloquer et les faire appeler personnellement pour vous demander de supprimer le blocage.

Faire appel à des gens semble être une mesure simple, mais cela permet de s’assurer qu’il y a un humain quelque part derrière l’ordinateur . La clé est que le blocage ne soit en place que pour une condition qui ne devrait presque jamais se produire sauf s’il s’agit d’un bot (par exemple, échouer plusieurs fois de suite dans la vérification). Ensuite, il FORCE l’interaction humaine - pour prendre le téléphone.

En réponse à la suggestion de les appeler à moi, il y a évidemment ce compromis ici. Etes-vous suffisamment inquiet pour vous assurer que vos utilisateurs sont suffisamment humains pour accepter quelques appels téléphoniques lorsqu'ils sont mis en vente? Si j'étais tellement préoccupé par le fait qu'un produit parvienne aux utilisateurs humains, je devrais prendre cette décision, en sacrifiant peut-être un peu de mon temps au cours du processus.

Puisqu'il semble que vous êtes déterminé à ne pas laisser les robots prendre le dessus sur votre site, je pense que le téléphone peut être une bonne option. Étant donné que je ne tire aucun profit de votre produit, je n'ai aucun intérêt à recevoir ces appels. Si vous partagiez une partie de ce profit, je pourrais être intéressé. Comme il s’agit de votre produit, vous devez décider combien vous en tenez et mettre en œuvre en conséquence.

Les autres moyens de libérer le bloc ne sont tout simplement pas aussi efficaces: un délai d'attente (mais ils verront votre site claquer à nouveau après, rinçage-répétition), un délai d'attente long (s'il s'agissait vraiment d'un humain essayant d'acheter votre produit, ils seraient SOL et punis pour avoir échoué le chèque), email (facilement fait par des robots), fax (même), ou courrier postal (prend trop de temps).

Vous pouvez bien entendu, au lieu de cela, augmenter la période de délai d’attente par adresse IP chaque fois qu’ils obtiennent un délai d’expiration. Assurez-vous simplement que vous ne punissez pas les vrais humains par inadvertance.

Autres conseils

Vous devez trouver un moyen de faire en sorte que les bots achètent des trucs excessivement chers: écrou à oreilles de 12 mm: 20 $. Voyez combien de robots se joignent avant que les scénaristes décident que vous les jouez.

Utilisez les bénéfices pour acheter plus de serveurs et payer pour la bande passante.

Ma solution serait de rendre inutile le grattage d’écran en prévoyant un délai d’environ 10 minutes pour les 'robots et les scripts.

Voici comment je le ferais:

  • Connectez-vous et identifiez tous les frappeurs récurrents.

Vous n'avez pas besoin de consigner chaque adresse IP pour chaque hit. Suivre seulement un coup sur 20 ou plus. Un récidiviste apparaîtra toujours dans un suivi occasionnel aléatoire.

  • Conservez le cache de votre page environ 10 minutes plus tôt.

  • Lorsqu'un frappeur répété / bot frappe votre site, donnez-leur l'ancienne page en cache de 10 minutes.

Ils ne sauront pas immédiatement qu’ils obtiennent un ancien site. Ils seront capables de tout gratter, mais ils ne gagneront plus aucune course, car "de vraies personnes" aura 10 minutes d'avance.

Avantages:

  • Pas de soucis ni de problèmes pour les utilisateurs (comme les CAPTCHAs).
  • Entièrement implémenté côté serveur. (pas besoin de Javascript / Flash)
  • Servir une page mise en cache plus ancienne devrait nécessiter moins de performances qu'une page en direct. Vous pouvez réellement réduire la charge de vos serveurs de cette façon!

Inconvénients

  • Nécessite le suivi de certaines adresses IP
  • Nécessite de conserver et de conserver un cache d'anciennes pages.

Qu'en pensez-vous?

Consultez cet article de ned Batchelder ici . Son article traite de l'arrêt des robots spammeurs, mais les mêmes techniques pourraient facilement s'appliquer à votre site.

  

Plutôt que d’arrêter les robots en ayant   les gens s'identifient, on peut   arrêter les robots en rendant difficile   pour eux de faire un post réussi, ou   en les faisant identifier par inadvertance   eux-mêmes comme des bots. Cela supprime le   fardeau des gens, et laisse le   formulaire de commentaire sans anti-spam visible   mesures.

     

Cette technique est la façon dont je préviens   spambots sur ce site. Ça marche. le   méthode décrite ici ne regarde pas   le contenu du tout.

Quelques autres idées:

  • Créez un mécanisme officiel de notification automatique (flux RSS? Twitter?) auquel les utilisateurs peuvent s'abonner lors de la mise en vente de votre produit. Cela réduit le besoin permettant aux utilisateurs de créer des scripts.
  • Modifiez votre technique d'obfuscation juste avant de mettre un nouvel objet en vente. Ainsi, même si les scripteurs peuvent intensifier la course aux armements, ils ont toujours un jour de retard.

EDIT: Pour être tout à fait clair, l’article de Ned ci-dessus décrit des méthodes permettant d’empêcher l’ACHAT automatisé d’objets en empêchant un BOT de parcourir les formulaires pour soumettre une commande. Ses techniques ne seraient pas utiles pour empêcher les robots de nettoyer la page d’accueil de leur écran pour déterminer le moment où un bandoulier de carottes serait mis en vente. Je ne suis pas sûr qu'il soit vraiment possible d'empêcher CELA.

En ce qui concerne vos commentaires sur l'efficacité des stratégies de Ned: Oui, il discute des pots de miel, mais je ne pense pas que ce soit sa stratégie la plus forte. Sa discussion sur SPINNER est la raison initiale pour laquelle j'ai mentionné son article. Désolé de ne pas l'avoir précisé dans mon message d'origine:

  

Le compteur est un champ caché utilisé pour   quelques choses: il hache ensemble un   nombre de valeurs qui empêchent   la falsification et les replays, et est utilisé pour   noms de champs obscurs. Le spinner est un   MD5 hash de:

     
      
  • l'horodatage,
  •   
  • l'adresse IP du client,
  •   
  • L'identifiant de l'entrée de blog faisant l'objet de commentaires et
  •   
  • Un secret.
  •   

Voici comment vous pouvez implémenter cela sur WOOT.com:

Modifier le " secret " valeur utilisée dans le hachage chaque fois qu'un nouvel élément est mis en vente. Cela signifie que si quelqu'un conçoit un BOT pour acheter automatiquement des articles, cela ne fonctionnera que jusqu'à la vente du prochain article !!

Même si quelqu'un est capable de reconstruire rapidement son bot, tous les autres utilisateurs réels auront déjà acheté un BOC et votre problème sera résolu!

L’autre stratégie dont il discute consiste à changer la technique du pot de miel de temps en temps (à nouveau, changez-la lorsqu'un nouvel article est en vente):

  • Utilisez des classes CSS (aléatoires bien sûr) pour définir les champs ou un élément contenant à afficher: aucun.
  • Colorez les champs de la même manière (ou très similaire) à l’arrière-plan de la page.
  • Utilisez le positionnement pour déplacer un champ hors de la zone visible de la page.
  • Créez un élément trop petit pour afficher le champ contenant le pot de miel.
  • Laissez les champs visibles, mais utilisez le positionnement pour les couvrir avec un élément obscurcissant.
  • Utilisez Javascript pour effectuer ces modifications, ce qui nécessite qu'un bot ait un moteur Javascript complet.
  • Laissez les pots de miel affichés comme les autres champs, mais dites aux personnes de ne rien entrer.

Je suppose que mon idée générale est de CHANGER LE DESIGN DU FORMULAIRE lorsque chaque nouvel article est mis en vente. Ou au moins, changez-le quand un nouveau BOC est en vente.

Quel est quoi, quelques fois par mois?

Si vous acceptez cette réponse, pouvez-vous me prévenir quand la prochaine réponse est due? :)

Q: Comment empêcheriez-vous les scripteurs de claquer votre site des centaines de fois par seconde?
A: Tu ne le fais pas. Il n’existe aucun moyen d’empêcher ce comportement par des agents externes.

Vous pouvez utiliser une vaste gamme de technologies pour analyser les demandes entrantes et tenter de manière heuristique de déterminer qui est un être humain ou non ... mais cela échouerait. Finalement, sinon immédiatement.

La seule solution viable à long terme consiste à changer le jeu afin que le site ne soit pas convivial pour les robots ou moins attrayant pour les scripteurs.

Comment faites-vous cela? Eh bien, c'est une question différente! ; -)

...

OK, certaines options ont été données (et rejetées) ci-dessus. Je ne connais pas très bien votre site, je ne l'ai regardé qu'une seule fois, mais comme les gens peuvent lire du texte dans les images et que les robots ne peuvent pas le faire facilement, changez l'annonce en image. Pas un CAPTCHA , juste une image -

  • générer l'image (mise en cache bien sûr) lorsque la page est demandée
  • conservez le même nom de source d'image, afin que le jeu ne disparaisse pas
  • la plupart du temps, l'image contiendra un texte ordinaire et sera alignée pour faire partie de la page HTML incorporée
  • lorsque le jeu est 'activé', l'image est remplacée par le texte de l'annonce
  • le texte de l'annonce révèle une URL et / ou un code à saisir manuellement pour acquérir le lot. CAPTCHA le code si vous voulez, mais ce n'est probablement pas nécessaire.
  • pour plus de sécurité, le code peut être un jeton ponctuel généré spécifiquement pour la requête / IP / l'agent, de sorte que les requêtes répétées génèrent des codes différents. Ou vous pouvez pré-générer un tas de codes aléatoires (un tampon unique) si la génération à la demande est trop éprouvante.

Exécutez des essais sur le temps de vraies personnes qui répondent à cette question et ignorez les réponses plus rapidement que la moitié de ce temps (par exemple, une erreur est survenue, désolée! veuillez réessayer). Cet événement devrait également déclencher une alerte pour les développeurs indiquant qu'au moins un bot a identifié le code / jeu. Il est donc temps de le modifier.

Continuez malgré tout à changer périodiquement le jeu, même si aucun robot ne le déclenche, mais simplement pour faire perdre du temps aux scripteurs. Finalement, les scripteurs devraient se lasser du jeu et aller ailleurs ... nous espérons ;-)

Une dernière suggestion: lorsqu'une demande de votre page principale arrive, placez-la dans une file d'attente et répondez aux demandes dans l'ordre dans un processus séparé (vous devrez peut-être pirater / étendre le Web). serveur pour le faire, mais cela en vaudra la peine). Si une autre demande du même agent IP / agent arrive alors que la première demande est dans la file d'attente, ignorez-la. Cela devrait automatiquement libérer la charge des robots.

EDIT: une autre option, en dehors de l’utilisation des images, consiste à utiliser du javascript pour compléter le texte "achat / non-achat"; les robots interprètent rarement javascript, ils ne le verront donc pas

Je ne sais pas à quel point c'est faisable: ... passez à l'offensive.

Déterminez les données recherchées par les robots. Donnez-leur les données qu’ils recherchent lorsque vous ne vendez PAS la merde. Faites-le de manière à ne pas déranger ni dérouter les utilisateurs humains. Lorsque les bots déclenchent la phase deux, ils se connectent et remplissent le formulaire pour acheter 100 $ de chambre au lieu de BOC. Bien entendu, cela suppose que les robots ne sont pas particulièrement robustes.

Une autre idée est d’appliquer des baisses de prix aléatoires tout au long de la période de vente. Qui achèterait un sac au hasard pour 150 dollars lorsque vous déclarez clairement qu'il ne vaut que 20 dollars? Personne sauf les zots excessifs. Mais alors 9 minutes plus tard, c'est 35 dollars ... puis 17 minutes plus tard, c'est 9 dollars. Ou peu importe.

Bien sûr, les rois zombies pourraient réagir. Le but est de rendre leurs erreurs très coûteuses (et de vous faire payer pour les combattre).

Tout cela suppose que vous souhaitiez faire chier certains botlords, ce qui pourrait ne pas être conseillé à 100%.

Le problème semble donc vraiment être que les bots veulent leur "sac à main". parce qu'il a une valeur perçue élevée à un prix perçu bas. Vous proposez parfois cet objet et les robots guettent, attendant de voir s'il est disponible, puis ils l'achètent.

Puisqu'il semble que les propriétaires de bot réalisent un profit (ou le réalisent potentiellement), l'astuce consiste à le rendre non rentable pour eux en les encourageant à acheter la merde.

Tout d'abord, toujours proposez le "sac à main".

Deuxièmement, assurez-vous que la merde est généralement de la merde.

Troisièmement, faites fréquemment tourner la merde.

Simple, non?

Vous aurez besoin d’un poste permanent "Pourquoi notre merde est-elle parfois de la merde?" lien à côté de l'offre pour expliquer aux humains ce qui se passe.

Lorsque le bot s'aperçoit qu'il y a de la merde et que la merde est automatiquement achetée, le destinataire sera terriblement fâché d'avoir payé 10 $ pour un cure-dent cassé. Et puis un sac poubelle vide. Et ensuite, de la terre au bas de votre chaussure.

S'ils achètent assez de cette merde dans un laps de temps relativement court (et que vous avez de gros avertissements expliquant pourquoi vous le faites), ils vont perdre un "sac" d'argent liquide " ; sur votre "sac" o crap ". Même une intervention humaine de leur part (vérifier que la merde n'est pas de la merde) peut échouer si vous faites tourner la merde assez souvent. Heck, peut-être que les bots remarqueront et n'achèteront pas ce qui est dans la rotation depuis trop peu de temps, mais cela signifie que les humains achèteront le non-merde.

Heck, vos clients habituels pourraient être tellement amusés que vous pouvez transformer cela en un énorme gain en marketing. Commencez à publier la quantité de "merde" " la carpe est vendue. Les gens vont revenir pour voir à quel point les robots ont été mordus.

Mise à jour: je m'attends à ce que vous receviez quelques appels à l'avance avec des personnes se plaignant. Je ne pense pas que vous puissiez arrêter cela complètement. Cependant, si cela tue les robots, vous pouvez toujours l'arrêter et le redémarrer plus tard.

  
      
  1. Vendez l'élément à des humains sans script.

  2.   
  3. Maintenez le site Web à une vitesse qui ne soit pas ralentie par les robots.

  4.   
  5. N'imposez aucune tâche aux utilisateurs "normaux" pour prouver qu'ils sont humains.

  6.   

Vous ne voulez probablement pas entendre cela, mais les numéros 1 et 3 s’excluent mutuellement.

Sur Internet, personne ne sait que vous êtes un chien

Eh bien, personne ne sait que vous êtes un bot non plus. Il n’existe aucun moyen programmatique de déterminer s’il existe ou non un humain à l’autre bout de la connexion sans demander à la personne de faire quelque chose. Empêcher les scripts / robots de faire des choses sur le Web est la raison pour laquelle les CAPTCHA ont été inventés. Ce n'est pas comme si c'était un nouveau problème pour lequel on n'avait pas déployé beaucoup d'efforts. S'il y avait une meilleure façon de le faire, une solution qui n'impliquerait pas de tracas pour les vrais utilisateurs comme le fait un CAPTCHA, tout le monde l'utiliserait déjà.

Je pense que vous devez faire face au fait que si vous voulez garder les bots de votre page de commande, un bon CAPTCHA est la seule façon de le faire. Si la demande pour votre merde aléatoire est suffisamment forte pour que les gens soient prêts à faire tout ce qui est en leur pouvoir pour l'obtenir, les utilisateurs légitimes ne seront pas rebutés par un CAPTCHA.

La méthode utilisée par Woot pour lutter contre ce problème modifie littéralement le jeu. Lorsqu’ils présentent un article extrêmement souhaitable à la vente, ils incitent les utilisateurs à jouer à un jeu vidéo pour le commander.

Non seulement cela permet de combattre efficacement les bots (ceux-ci peuvent facilement apporter des modifications mineures au jeu pour éviter les joueurs automatiques, ou même fournir un nouveau jeu pour chaque vente), mais il donne également l'impression aux utilisateurs de "gagner". l'élément souhaité tout en ralentissant le processus de commande.

Cela se vend encore très vite, mais je pense que la solution est bonne: réévaluer le problème et modifier les paramètres ont conduit à une stratégie réussie dans laquelle des solutions strictement techniques n'existaient tout simplement pas.

L’ensemble de votre modèle commercial repose sur "Premier arrivé, premier servi". Vous ne pouvez pas faire ce que les stations de radio ont fait (elles ne font plus du premier appelant le gagnant, elles désignent le 5e, 20e ou 13e appelant le gagnant) - cela ne correspond pas à votre fonction principale.

Non, il n'y a aucun moyen de le faire sans modifier l'expérience de commande des utilisateurs réels.

Disons que vous mettez en œuvre toutes ces tactiques. Si je décide que cela est important, je demanderai simplement à 100 personnes de travailler avec moi, nous construirons un logiciel qui fonctionnera sur nos 100 ordinateurs distincts et nous visionnerons votre site 20 fois par seconde (5 secondes entre les accès pour chaque utilisateur / cookie / compte / adresse IP).

Vous avez deux étapes:

  1. Visionnage de la page d'accueil
  2. Commande

Vous ne pouvez pas mettre un blocage captcha # 1 - cela va perdre de vrais clients ("Quoi? Je dois résoudre un captcha chaque fois que je veux voir le dernier woot?!?").

Donc, mon petit groupe surveille, chronométré ensemble, nous obtenons environ 20 contrôles par seconde, et celui qui voit le changement en premier alerte (automatiquement) tous les autres, qui chargera à nouveau la page d'accueil, suivra le lien de commande, et effectuera la transaction (qui peut également se produire automatiquement, sauf si vous implémentez captcha et que vous le modifiez à chaque démarrage / démarrage).

Vous pouvez placer un captcha devant le n ° 2 et, même si vous êtes réticent à le faire, c'est peut-être le seul moyen de vous assurer que même si les bots regardent la page de couverture, de vrais utilisateurs obtiennent les produits.

Mais même avec captcha, mon petit groupe de 100 aurait tout de même un avantage considérable sur le premier arrivé - et il n’est pas possible que vous sachiez que nous ne sommes pas humains. Si vous commencez à chronométrer nos accès, nous ajouterions simplement un peu de gigue. Nous pouvons sélectionner au hasard l'ordinateur qui doit être actualisé pour que l'ordre des accès change constamment, tout en conservant un aspect humain.

D'abord, débarrassez-vous des simples robots

Vous devez avoir un pare-feu adaptatif qui surveille les demandes et si quelqu'un fait la bêtise évidente - rafraîchir plus d'une fois par seconde à la même adresse IP, puis employer des tactiques pour les ralentir (rejeter les paquets, renvoyer refusé ou 500 erreurs, etc.).

Cela devrait considérablement réduire votre trafic et modifier les tactiques employées par les utilisateurs de bot.

Deuxièmement, accélérez extrêmement rapidement le serveur.

Vous ne voulez vraiment pas entendre ça ... mais ...

Je pense que vous avez besoin d'une solution entièrement personnalisée de bas en haut.

Vous n'avez pas besoin de manipuler la pile TCP / IP, mais vous devrez peut-être développer un serveur personnalisé très, très rapide, conçu pour corréler les connexions des utilisateurs et réagir de manière appropriée à diverses attaques.

Apache, lighthttpd, etc. sont excellents pour la flexibilité, mais vous n’exécutez qu'un seul site Web et vous devez vraiment pouvoir faire plus que ce que les serveurs actuels sont capables de faire (à la fois pour la gestion du trafic et pour la gestion du trafic). combattre de manière appropriée les robots).

En servant une page Web en grande partie statique (mises à jour toutes les 30 secondes environ) sur un serveur personnalisé, vous ne devriez pas être en mesure de gérer 10 fois le nombre de demandes et de trafic (car le serveur ne fait rien d'autre que recevoir la demande. et lire la page de mem

Avertissement: Cette réponse n’est absolument pas liée à la programmation. Cependant, il tente en premier lieu d’attaquer le motif des scripts.

Une autre idée est que si vous avez vraiment une quantité limitée à vendre, pourquoi ne la changez-vous pas de la méthode du premier arrivé, premier servi? À moins, bien sûr, que le battage publicitaire fasse partie de votre stratégie marketing.

Il existe de nombreuses autres options, et je suis sûr que d’autres peuvent en penser différentes:

  • une file d'attente de commandes (système de précommande) - Certains scripts peuvent toujours se retrouver en tête de la file d'attente, mais il est probablement plus rapide de saisir manuellement les informations.

  • un système de tirage au sort (tous ceux qui essaient d'en commander un sont entrés dans le système) - Ainsi, les personnes avec les scripts ont exactement les mêmes chances que celles qui n'en ont pas.

  • une file d'attente prioritaire - Si la valeur perçue est vraiment élevée, les gens peuvent être disposés à payer plus. Implémentez une file d'attente de commande, mais permettez aux gens de payer plus pour être placés plus haut dans la file d'attente.

  • enchère (le mérite revient à David Schmitt pour celui-ci, les commentaires sont les miens) - Les gens peuvent toujours utiliser des scripts pour fouiller à la dernière minute, mais ils ne se contentent pas de changer la structure de prix se battre avec d'autres. Vous pouvez également faire des choses pour limiter le nombre d’enchères dans une période donnée, obliger les gens à téléphoner à l’avance pour obtenir un code d’autorisation, etc.

Même si les nazis pensaient que leurs communications étaient en sécurité, les alliés cassaient souvent leurs messages. Peu importe la façon dont vous essayez d'empêcher les bots d'utiliser votre site, les propriétaires de bot trouveront un moyen de le contourner. Je suis désolé si cela fait de vous le nazi: -)

Je pense qu'un état d'esprit différent est nécessaire

  • N'essayez pas d'empêcher les robots d'utiliser votre site
  • Ne cherchez pas un correctif qui fonctionne immédiatement, jouez au long jeu

Indiquez que le client de votre site est un humain ou un bot, tous deux ne font que payer des clients; mais l'un a un avantage injuste sur l'autre. Certains utilisateurs sans grande vie sociale (ermites) peuvent être aussi ennuyeux que les bots pour les autres utilisateurs de votre site.

Enregistrez le moment où vous publiez une offre et le moment où un compte décide de l'acheter.

  

Ceci vous donne un enregistrement de la vitesse à laquelle   le client achète des choses.

Modifiez l'heure à laquelle vous publiez des offres.

  

Par exemple, ayez une fenêtre de 3 heures   en commençant à un moment obscur de la   jour (minuit?) Seuls les bots et les ermites   va constamment actualiser une page pour 3   heures juste pour obtenir un ordre dans les   secondes. Ne jamais modifier le temps de base,   seulement la taille de la fenêtre.

Au fil du temps, une image apparaîtra.

01: vous pouvez voir quels comptes achètent régulièrement des produits quelques secondes après leur mise en ligne. Suggérant qu’ils pourraient être des bots.

02: Vous pouvez également consulter la fenêtre de temps utilisée pour les offres. Si la fenêtre dure 1 heure, certains des premiers acheteurs seront des êtres humains. Un humain sera rarement rafraîchi pendant 4 heures. Si le temps écoulé est assez cohérent entre publication / achat, quelle que soit la durée de la fenêtre, il s'agit d'un bot. Si le temps de publication / d'achat est court pour les petites fenêtres et plus long pour les grandes fenêtres, c'est un ermite!

Maintenant, au lieu d'empêcher les robots d'utiliser votre site, vous avez suffisamment d'informations pour savoir quels comptes sont certainement utilisés par les robots et quels comptes sont susceptibles d'être utilisés par des ermites. Ce que vous faites avec ces informations vous appartient, mais vous pouvez certainement vous en servir pour rendre votre site plus équitable pour les personnes qui ont une vie.

Je pense qu'interdire les comptes de bot serait inutile, cela reviendrait à téléphoner à Hitler et à lui dire "Merci pour la position de vos sous-marins!" D'une manière ou d'une autre, vous devez utiliser les informations d'une manière que les titulaires du compte ne réaliseront pas. Voyons si je peux rêver n'importe quoi .....

Traiter les commandes d'une file d'attente:

Lorsque le client passe une commande, il reçoit immédiatement un e-mail de confirmation l'informant que sa commande est placée dans une file d'attente et sera avertie de son traitement. J'éprouve ce genre de problème avec la commande / l'envoi sur Amazon et cela ne me dérange pas du tout. Cela ne me dérange pas de recevoir un e-mail quelques jours plus tard me disant que ma commande a été expédiée tant que je reçois immédiatement un e-mail me disant que Amazon sait que je veux le livre. Dans votre cas, ce serait un email pour

  1. Votre commande a été passée et est dans une file d'attente.
  2. Votre commande a été traitée.
  3. Votre commande a été expédiée.

Les utilisateurs pensent être dans une file d'attente normale. Traitez votre file d'attente toutes les heures afin que les utilisateurs normaux en fassent également l'expérience, afin de ne pas éveiller les soupçons. Ne traitez que les commandes des comptes bot et ermite une fois qu’ils ont été mis dans la file d'attente pour le "temps de commande humain moyen + x heures". Réduire efficacement les robots pour les humains.

Je dis exposer les informations de prix en utilisant une API. C'est une solution peu intuitive, mais elle fonctionne pour vous permettre de contrôler la situation. Ajoutez quelques limitations à l’API pour la rendre légèrement moins fonctionnelle que le site Web.

Vous pouvez faire la même chose pour les commandes. Vous pouvez expérimenter de petites modifications de la fonctionnalité / des performances de l'API jusqu'à ce que vous obteniez l'effet souhaité.

Il existe des proxies et des réseaux de zombies pour éviter les contrôles IP. Il y a des scripts de lecture captcha qui sont extrêmement bons. Il y a même des équipes de travailleurs en Inde qui défont les captchas pour un petit prix. Toute solution que vous pouvez trouver peut être raisonnablement vaincue. Même les solutions de Ned Batchelder peuvent être dépassées en utilisant un contrôle WebBrowser ou un autre navigateur simulé combiné à un botnet ou à une liste de proxy.

Nous utilisons actuellement la dernière génération d'équilibreurs de charge BigIP de F5. BigIP dispose de fonctionnalités avancées de gestion du trafic qui permettent d’identifier les robots de raclage en fonction de la fréquence et des modes d’utilisation, même à partir d’un ensemble de sources situées derrière une adresse IP unique. Il peut ensuite les limiter, leur proposer un contenu alternatif ou simplement les étiqueter avec des en-têtes ou des cookies afin que vous puissiez les identifier dans le code de votre application.

Pourquoi ne pas introduire un délai qui nécessite une interaction humaine, comme une sorte de "jeu CAPTCHA". Par exemple, il pourrait s’agir d’un petit jeu Flash dans lequel, pendant 30 secondes, ils doivent faire éclater des boules à carreaux et éviter d’éclater des boules solides (éviter les problèmes de daltonisme!). Une graine de nombre aléatoire sera attribuée au jeu. Ce que le jeu transmettra au serveur correspondra aux coordonnées et à l'horodatage des points cliqués, ainsi que la graine utilisée.

Sur le serveur, vous simulez les mécanismes de jeu en utilisant cette graine pour voir si les clics auraient effectivement fait éclater les balles. S'ils le faisaient, non seulement ils étaient humains, mais ils mettaient 30 secondes pour se valider. Donnez-leur un identifiant de session.

Vous laissez cet identifiant de session faire ce qu'il veut, mais s'il fait trop de demandes, il ne peut pas continuer sans jouer à nouveau.

Tout d’abord, laissez-moi récapituler ce que nous devons faire ici. Je me rends bien compte que je ne fais que paraphraser la question initiale, mais il est important que nous comprenions tout à l’heure, car il existe de très bonnes suggestions qui répondent parfaitement à 2 ou 3 sur 4, mais comme je vais vous le montrer, approche multifacettes pour couvrir toutes les exigences.

Condition 1: Éliminer le 'bot slamming':

Le slamming rapide de votre page de couverture nuit aux performances de votre site et est au cœur du problème. Le «slamming» provient à la fois de bots mono-IP et, supposément, de botnets. Nous voulons nous débarrasser des deux.

Condition 2: ne jouez pas avec l'expérience utilisateur:

Nous pourrions résoudre le problème des robots de manière assez efficace en mettant en œuvre une procédure de vérification très dure, comme téléphoner à un opérateur humain, résoudre un ensemble de CAPTCHA ou similaires, mais cela reviendrait à obliger tout passager d'avion innocent à passer à travers des cerceaux de sécurité fous juste pour la mince chance d'attraper le plus stupide des terroristes. Oh, attends, c'est ce que nous faisons. Mais voyons si nous pouvons ne pas le faire sur woot.com.

Condition 3: éviter la "course aux armements":

Comme vous le mentionnez, vous ne voulez pas vous laisser entraîner dans la course aux armements en spambots. Vous ne pouvez donc pas utiliser de simples modifications telles que des champs de formulaire cachés ou brouillés, des questions mathématiques, etc., car il s'agit essentiellement de mesures d'obscurité pouvant être trivialement détectées et contournées.

Condition préalable 4: déjouer les robots "d'alarme":

C’est peut-être le plus difficile de vos besoins. Même si nous sommes en mesure de relever le défi de la vérification humaine, les robots peuvent toujours consulter votre page de garde et alerter le scripteur lorsqu’une nouvelle offre est présentée. Nous voulons aussi rendre ces robots impraticables. Ceci est une version plus forte de la première exigence, car non seulement les bots ne peuvent pas envoyer de requêtes de tir rapide dommageables pour la performance, mais ils ne peuvent même pas envoyer assez de requêtes répétées pour envoyer une "alarme" au scripteur à temps pour gagner. l'offre.

D'accord, alors voyons si nous pouvons répondre aux quatre exigences. Tout d’abord, comme je l’ai mentionné, aucune mesure ne peut faire l’essentiel. Pour y parvenir, vous devrez combiner quelques astuces et avaler deux ennuis:

  1. Un petit nombre d'utilisateurs sera nécessaire pour franchir les étapes
  2. Un petit nombre d'utilisateurs ne pourront pas recevoir les offres spéciales

Je me rends compte que ce sont ennuyeux, mais si nous pouvons faire en sorte que le "petit" nombre soit suffisamment petit , j'espère que vous conviendrez que les avantages l'emportent sur les inconvénients.

Première mesure: limitation par l'utilisateur:

  

Celui-ci est une évidence, et je suis sûr que vous le faites déjà. Si un utilisateur est connecté et continue d'actualiser 600 fois par seconde (ou quelque chose du genre), vous cessez de répondre et lui dites de le laisser refroidir. En fait, vous étouffez probablement ses demandes beaucoup plus tôt que cela, mais vous avez l’idée. De cette façon, un bot connecté sera banni / contrôlé dès qu'il commencera à interroger votre site. C'est la partie facile. Les robots non authentifiés sont notre vrai problème, ainsi de suite:

Deuxième mesure: une forme de limitation de la propriété intellectuelle suggérée par presque tout le monde:

  

Quoi qu’il en soit, vous devrez utiliser une limitation IP pour contrecarrer le «bot qui claque». Dans la mesure où il vous semble important d'autoriser les visiteurs non authentifiés (non connectés) à bénéficier d'offres spéciales, vous ne pouvez utiliser que les adresses IP dans un premier temps. Bien qu'elles ne soient pas parfaites, elles fonctionnent contre les robots mono-IP. Les botnets sont une bête différente, mais j'y reviendrai. Pour le moment, nous allons faire quelques manœuvres simples pour vaincre les bots mono-IP à tir rapide.

     

La baisse de performance est négligeable si vous exécutez la vérification IP avant tout autre traitement, utilisez un serveur proxy pour la limitation.logique et stockez les adresses IP dans une arborescence optimisée pour la recherche avec memcached.

Troisième mesure: masquer l'accélérateur avec les réponses en cache:

  

Avec le ralentissement des bots mono-IP à tir rapide, nous devons toujours nous attaquer aux bots lents à simple IP, c'est-à-dire. les robots spécialement conçus pour "voler sous le radar" en espaçant les requêtes légèrement plus éloignées que ne le permet la limitation.

     

Pour rendre instantanément inutiles les bots à une seule adresse lents, utilisez simplement la stratégie suggérée par abelenky: servez des pages en mémoire cache datant de 10 minutes à toutes les adresses IP repérées au cours des dernières 24 heures (ou plus). De cette façon, chaque adresse IP a une «chance» par jour / heure / semaine (selon la période que vous choisissez), et il n'y aura aucune gêne visible pour les vrais utilisateurs qui ne font que «recharger», sauf qu'ils ne gagnent pas. l'offre.

     

La beauté de cette mesure est que également les "bots d'alarme" sont interdits, tant qu'ils ne proviennent pas d'un botnet.

     

(Je sais que vous préféreriez probablement que de vrais utilisateurs soient autorisés à actualiser encore et encore, mais il n'y a aucun moyen de distinguer un humain de rafraîchissement-spam à partir d'un bot de spam-requête séparé sans CAPTCHA ou similaire)

Quatrième mesure: reCAPTCHA:

  

Vous avez raison de dire que les CAPTCHA nuisent à l'expérience de l'utilisateur et doivent être évités. Cependant, dans _one _ , ils peuvent être votre meilleur ami: si vous avez conçu un système très restrictif pour contrecarrer les robots, cela - en raison de son caractère restrictif - permet également de détecter un certain nombre de faux positifs; puis un CAPTCHA servi en dernier recours permettra aux vrais utilisateurs qui se font prendre de se laisser prendre par votre limitation (évitant ainsi les situations de DoS gênantes).

     

Naturellement, l’endroit idéal est que TOUS les robots se retrouvent pris dans votre filet, alors que très peu d’utilisateurs réels sont dérangés par le CAPTCHA.

     

Si vous proposez également des alternatives facultatives , une "mise à jour de page d'accueil" vérifiée par CAPTCHA lorsque vous servez les pages en cache datant de 10 minutes, alors les humains qui vraiment

strong> souhaite continuer à actualiser, peut toujours le faire sans récupérer l'ancienne page en cache, mais au prix de la résolution d'un problème CAPTCHA pour chaque actualisation. C'est un ennui, mais un optionnel réservé aux utilisateurs les plus assidus, qui ont tendance à être plus indulgent parce qu'ils savent qu'ils sont jouer au système pour améliorer leurs chances, et que les chances améliorées ne sont pas gratuites.

Cinquième mesure: merde leurre:

  

Christopher Mahan avait une idée qui me plaisait beaucoup, mais je lui donnerais une autre tournure. Chaque fois que vous préparez une nouvelle offre, préparez deux autres «offres» qu'aucun humain ne choisirait, comme un aileron de 12 mm pour 20 $. Lorsque l'offre apparaît sur la première page, mettez les trois offres dans la même image, en indiquant le numéro correspondant à chaque offre. Lorsque l'utilisateur / le bot passera la commande de l'article, il devra choisir (un bouton radio) l'offre qu'il souhaite, et puisque la plupart des robots ne font que deviner, dans deux cas sur trois, ils n'achèteront rien. junk.

     

Naturellement, cela ne concerne pas les «robots d’alarme», et il y a une (mince) chance que quelqu'un puisse créer un bot capable de choisir le bon article. Cependant, le risque d’achat accidentel de junk devrait amener les scripteurs à se tourner entièrement vers des robots entièrement automatisés.

Sixième mesure: limitation du botnet:

  

[supprimé]

D'accord ............ J'ai maintenant passé presque toute ma soirée à réfléchir à cela, à essayer différentes approches .... retards mondiaux .... jetons à base de biscuits .. service en file d'attente ... "étranger étranglement" .... Et ça ne fonctionne tout simplement pas. Ce n'est pas. J'ai compris que la principale raison pour laquelle vous n'aviez pas encore accepté de réponse était que personne n'avait proposé de moyen de déjouer un réseau / bot zombie / distribué.

Il y a quelques autres / meilleures solutions déjà publiées, mais par souci d'exhaustivité, j'ai pensé mentionner ceci:

Si votre principale préoccupation est la dégradation des performances et que vous envisagez de véritablement marteler , vous avez en fait une attaque par déni de service et vous devriez probablement essayer de la gérer en conséquence. Une approche courante consiste simplement à supprimer les paquets d'une adresse IP dans le pare-feu après un nombre de connexions par seconde / minute / etc. Par exemple, le pare-feu Linux standard, iptables, possède une fonction d’appariement d’opérations standard, "hashlimit", qui peut être utilisée pour corréler les demandes de connexion par unité de temps à une adresse IP.

Bien que cette question convienne probablement mieux pour le prochain dérivé de SO mentionné dans le dernier podcast de SO, il n'a pas encore été lancé, alors je suppose que vous pouvez répondre:)

EDIT:
Comme l'a souligné novatrust, il existe encore des fournisseurs de services Internet qui n'attribuent pas d'adresse IP à leurs clients. Par conséquent, un client scripté d'un tel fournisseur de services Internet désactiverait tous les clients de ce fournisseur d'accès.

Tout d’abord, par définition, il est impossible de prendre en charge des transactions sans état, c’est-à-dire véritablement anonymes, tout en pouvant séparer les robots des utilisateurs légitimes.

Si nous pouvons accepter le principe selon lequel nous pouvons imposer des coûts à un visiteur flambant neuf sur son premier hit de page, il me semble que j'ai une solution possible. En l'absence d'un meilleur nom, je vais appeler cette solution "Une visite au DMV".

Supposons qu’un concessionnaire propose une nouvelle voiture différente chaque jour et que, certains jours, vous pouvez acheter une voiture de sport exotique à 5 $ l'unité (maximum de 3), ainsi que des frais de destination de 5 $.

Le problème, c'est que le concessionnaire vous oblige à lui rendre visite et à lui montrer un permis de conduire valide avant de vous laisser entrer pour voir quelle voiture est en vente. De plus, vous devez avoir un permis de conduire valide pour pouvoir effectuer l'achat.

Ainsi, le premier visiteur (appelons-le Bob) de ce concessionnaire se voit refuser l'entrée et est dirigé vers le bureau du DMV (situé juste à côté) pour obtenir un permis de conduire.

Les autres visiteurs possédant un permis de conduire valide sont autorisés à entrer après avoir présenté son permis de conduire. Une personne qui se gêne en flânant toute la journée, harcelant les vendeurs, attrapant des brochures et vidant le café et les biscuits offerts finira par être refusée.

Maintenant, revenons à Bob sans licence - tout ce qu’il a à faire est de supporter une fois la visite au DMV. Après cela, il peut se rendre chez le concessionnaire et acheter des voitures quand il le souhaite, à moins qu’il ait accidentellement laissé son portefeuille à la maison ou que son permis soit détruit ou révoqué.

Le permis de conduire dans ce monde est presque impossible à contrefaire.

Pour vous rendre au DMV, vous devez d'abord obtenir le formulaire de candidature à l’adresse "Démarrer ici". queue. Bob doit prendre la demande dûment remplie dans la fenêtre 1, où le premier des nombreux fonctionnaires vexés va prendre sa demande, la traiter et, si tout est en ordre, tamponner la demande pour la fenêtre et l'envoyer à la fenêtre suivante. Et ainsi, Bob va de fenêtre en fenêtre, attendant la fin de chaque étape de sa demande, jusqu’à ce qu’il arrive enfin à la fin et reçoive son permis de conduire.

Il est inutile d'essayer de "court-circuiter" le DMV. Si les formulaires ne sont pas remplis correctement en triple exemplaire ou si des réponses erronées sont données à n’importe quelle fenêtre, l’application est déchirée et le client malchanceux est renvoyé au début.

Fait intéressant, peu importe le nombre de bureaux remplis ou vides, il faut à peu près le même temps pour obtenir des services à chaque fenêtre successive. Même lorsque vous êtes la seule personne en ligne, il semble que le personnel aime vous faire patienter une minute derrière la ligne jaune avant de prononcer "Suivant!".

Les choses ne sont pas si terribles au DMV, cependant. Pendant que les procédures d’attente et d’obtention de la licence sont en cours, vous pouvez visionner une annonce publicitaire informative très divertissante et informative destinée au concessionnaire automobile alors que vous êtes dans le hall DMV. En fait, l’infomérique fonctionne juste assez longtemps pour couvrir le temps que vous passez à obtenir votre licence.

L'explication un peu plus technique:

Comme je l’ai dit tout en haut, il est nécessaire d’avoir une relation explicite sur la relation client-serveur, qui vous permet de séparer les humains des robots. Vous voulez le faire de manière à ne pas trop pénaliser le visiteur humain anonyme (non authentifié).

Cette approche nécessite probablement un traitement côté client AJAX-y. Le tout nouveau visiteur de Woot se voit attribuer le message "Bienvenue au nouvel utilisateur!". page pleine de texte et de graphiques dont le chargement complet prend quelques secondes (avec une limitation appropriée côté serveur). Bien que cela se produise (et le visiteur est vraisemblablement occupé à lire la ou les pages d'accueil), son identificateur est lent

Vous ne pouvez pas totalement empêcher les bots, même avec un captcha. Cependant, vous pouvez avoir du mal à écrire et à maintenir un bot et donc à en réduire le nombre. En les forçant notamment à mettre à jour leurs robots quotidiennement, vous ferez perdre l'intérêt à beaucoup d'entre vous.

Voici quelques idées pour rendre plus difficile l’écriture de robots:

  • Nécessite l'exécution d'une fonction javascript. Javascript rend beaucoup plus difficile d'écrire un bot. Peut-être nécessiter un captcha s’ils n’exécutent pas javascript pour autoriser tout de même les utilisateurs non-javascript (minime)

  • Chronométrer les frappes au clavier lors de la saisie dans le formulaire (à nouveau via javascript). Si ce n'est pas humain, alors rejette-le. Il est difficile d'imiter le typage humain dans un bot.

  • Écrivez votre code pour mettre à jour quotidiennement vos identifiants de champ avec une nouvelle valeur aléatoire. Cela les obligera à mettre à jour leur bot quotidiennement, ce qui est pénible.

  • Écrivez votre code pour réorganiser vos champs tous les jours (évidemment, d'une manière qui ne soit pas aléatoire pour vos utilisateurs). S'ils se fient à l'ordre des champs, cela les déclenchera et obligera à nouveau la maintenance quotidienne à leur code bot.

  • Vous pouvez aller encore plus loin et utiliser du contenu Flash. Flash est totalement pénible pour écrire un bot contre.

En règle générale, si vous commencez par ne pas les prévenir, mais en leur donnant plus de travail, vous pourrez probablement atteindre l'objectif que vous recherchez.

Respectez un délai de 5 minutes pour toutes les annonces de produits destinées aux utilisateurs non enregistrés. Les utilisateurs occasionnels ne le remarqueront pas vraiment et les utilisateurs non habituels seront de toute façon enregistrés.

Je ne vois pas le grand fardeau que vous réclamez de la vérification des adresses IP entrantes. Au contraire, j'ai réalisé un projet pour l'un de mes clients qui analysait les journaux d'accès HTTP toutes les cinq minutes (cela aurait pu être en temps réel, mais il ne voulait pas cela pour une raison que je n'avais jamais entièrement comprise) et crée des règles de pare-feu pour bloquer les connexions de toute adresse IP générant un nombre excessif de demandes, à moins que l'adresse puisse être confirmée comme appartenant à un moteur de recherche légitime (Google, Yahoo, etc.).

Ce client exécute un service d'hébergement Web et exécute cette application sur trois serveurs qui gèrent un total de 800 à 900 domaines. Le pic d'activité se situe dans la plage des milliers de hits par seconde et il n'y a jamais eu de problème de performances: les pare-feu sont très efficaces pour supprimer les paquets d'adresses en liste noire.

Et, oui, la technologie DDOS existe bel et bien, ce qui irait à l’encontre de ce stratagème, mais il ne voit pas cela se produire dans le monde réel. Au contraire, il affirme que la charge de ses serveurs a été considérablement réduite.

Mon approche serait de mettre l’accent sur des solutions non technologiques (sinon vous entrez dans une course aux armements que vous perdrez, ou du moins vous passez beaucoup de temps et d’argent). Je me concentrerais sur les éléments de facturation / d'expédition - vous pouvez trouver des robots en trouvant plusieurs livraisons à la même adresse ou en chargeant plusieurs fois avec un seul mode de paiement. Vous pouvez même le faire pour plusieurs éléments pendant plusieurs semaines. Ainsi, si un utilisateur reçoit un élément précédent (en réagissant très rapidement), il se peut qu'il soit affecté à une sorte de "handicap". cette fois-ci.

Cela aurait également un effet secondaire (bénéfique, je pense, mais je peux me tromper de point de vue marketing pour votre cas) d’élargir peut-être le cercle des gens qui ont de la chance et qui peuvent acheter des woot.

La plupart des solutions purement techniques ont déjà été proposées. Je vais donc suggérer une autre vue du problème.

Si je comprends bien, les robots sont installés par des personnes véritablement qui essaient d'acheter les sacs que vous vendez. Le problème est -

  1. Les autres personnes qui n'exploitent pas de robots méritent une chance d'acheter et vous offrez un nombre limité de sacs.
  2. Vous voulez attirer des humains sur votre site et simplement vendre les sacs.

Au lieu d'essayer d'éviter les robots, vous pouvez permettre aux acheteurs potentiels de sacs de s'inscrire à un courrier électronique, voire à une mise à jour par SMS, pour être avertis du moment où une vente aura lieu. Vous pouvez même leur donner une minute ou deux d'avance (une URL spéciale où la vente commence, générée aléatoirement et envoyée avec le courrier / SMS).

Lorsque ces acheteurs achètent leur site, vous pouvez leur montrer ce que vous voulez dans des bannières ou autre. Ceux qui utilisent les robots préfèrent s’inscrire simplement auprès de votre service de notification.

Les coureurs de robots peuvent toujours exécuter des robots sur votre notification pour terminer l’achat plus rapidement. Certaines solutions peuvent être un achat en un clic.

A propos, vous avez mentionné que vos utilisateurs n'étaient pas enregistrés, mais il semblerait que ceux qui achètent ces sacs ne soient pas des acheteurs aléatoires, mais des personnes qui attendent ces ventes avec impatience. En tant que tels, ils pourraient être disposés à s’inscrire pour obtenir un avantage en essayant de "gagner" un sac.

Ce que je propose essentiellement, c’est d’essayer de considérer le problème comme un problème social plutôt que technique.

Asaf

Bloquez les agents utilisateurs qui font autant de demandes par minute. Par exemple, si quelqu'un demande une page exactement toutes les 5 secondes pendant 10 minutes, il ne s'agit probablement pas d'un utilisateur ... Mais il pourrait être difficile de bien faire les choses.

S'ils déclenchent une alerte, redirigez chaque requête vers une page statique avec aussi peu que possible DB-IO avec un message les informant qu'ils seront autorisés à revenir dans X minutes.

Il est important d'ajouter que vous ne devez probablement appliquer cette règle qu'aux demandes de pages et ignorer toutes les demandes de supports (js, images, etc.).

Empêcher les dénis de service annulerait le deuxième objectif de @ davebug, décrit ci-dessus: "Conservez le site à une vitesse qui ne soit pas ralentie par les bots". mais ne serait pas nécessaire de résoudre le problème n ° 1, "Vendre l'élément à des humains sans script"

Je suis sûr qu'un scripteur pourrait écrire quelque chose à skater juste en dessous de la limite excessive qui serait toujours plus rapide qu'un humain ne pourrait parcourir les formulaires de commande.

Très bien, les spammeurs sont en concurrence avec des gens ordinaires pour gagner le "marais de merde". enchères? Pourquoi ne pas faire de la prochaine vente aux enchères un véritable "sac de merde"? Les spammeurs doivent débourser beaucoup d’argent pour un sac rempli de chiens, et nous en rions tous.

La chose importante ici est de changer le système pour supprimer la charge de votre serveur, empêcher les bots de gagner le sac de la merde SANS laisser les botlords savoir que vous jouez ou ils vont réviser leur stratégie. Je ne pense pas qu'il soit possible de le faire sans un traitement de votre part.

Vous enregistrez donc les hits sur votre page d'accueil. Chaque fois qu'une personne visite la page, cette connexion est comparée à sa dernière connexion. Si elle était trop rapide, une version de la page lui est envoyée sans offre. Cela peut être fait par une sorte de mécanisme d'équilibrage de charge qui envoie des robots (les hits trop rapides) à un serveur qui sert simplement des versions en cache de votre page d'accueil; de vraies personnes sont envoyées au bon serveur. Cela soulage le serveur principal et fait penser aux robots que les pages sont toujours servies correctement.

Encore mieux si l’offre peut être refusée d’une manière ou d’une autre. Ensuite, vous pouvez toujours faire les offres sur le faux serveur, mais lorsque le bot remplit le formulaire, dites "Désolé, vous n’êtes pas assez rapide". :) Ensuite, ils vont certainement penser qu'ils sont toujours dans le match.

Comment savez-vous que des scripteurs passent des commandes?

Le problème essentiel est que vous ne pouvez pas séparer les scripteurs des utilisateurs légitimes, vous ne pouvez donc pas les bloquer. Comment se fait-il que vous sachiez qu'il existe des scripteurs?

Si vous avez un moyen de répondre à cette question, vous disposez d'un ensemble de caractéristiques que vous pouvez utiliser pour filtrer les scripteurs.

Retournons le problème. Vous avez des robots qui achètent des choses que vous voulez que de vraies personnes achètent. Pourquoi ne pas leur donner une chance réelle d'acheter des choses que vous ne voulez pas ? de vraies personnes à acheter.

Avoir une chance au hasard pour certains html non affichés que les robots collecteurs penseront être la situation réelle, mais que les vraies personnes ne verront pas (et n'oubliez pas que les vraies personnes incluent les aveugles, pensez donc aux lecteurs d'écran, etc. ), et cela vous achète quelque chose d’énormément cher (ou n’effectue pas l’achat proprement dit, mais il vous donne les détails du paiement pour que vous puissiez le mettre sur une liste banique).

Même si les robots basculent sur "alerter l'utilisateur" plutôt que sur "achat", si vous obtenez assez de fausses alarmes, vous pourrez peut-être le rendre suffisamment inutile pour les gens (peut-être pas tout le monde, mais l'escroquerie est mieux que rien du tout) pour ne pas déranger.

scroll top