J'ai accepté une réponse, mais malheureusement, je crois que nous sommes coincés avec notre pire scénario d'origine: CAPTCHA tout le monde sur les tentatives d'achat de la merde . Brève explication: les fermes de mise en cache / Web rendent impossible le suivi des hits, et toute solution de contournement (envoi d'une balise Web non mise en cache, écriture dans une table unifiée, etc.) ralentit le site pire que les bots. 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 tout le monde est une alternative. Je vais essayer une explication plus complète plus tard, ainsi que le nettoyage pour les futurs chercheurs (bien que d'autres soient invités à essayer, car c'est le wiki de la communauté).

Situation

Il s'agit des ventes de bag o 'crap sur woot.com. Je suis le président de Woot Workshop, la filiale de Woot qui fait la conception, écrit les descriptions de produits, les podcasts, les articles de blog et anime 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 parlé 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 passionnant et amusant est la majeure partie du reste. C'est là que dérivent les trois objectifs ci-dessous. CAPTCHA nuit à la convivialité et les robots volent le plaisir et l'excitation de nos ventes de merde.

Les bots claquent notre page d'accueil des dizaines de fois par seconde en grattant l'écran (et / ou en scannant notre RSS) pour la vente Random Crap. Au moment où ils voient cela, il déclenche une deuxième étape du programme qui se connecte, clique sur Je veux un, remplit le formulaire et achète la merde.

Évaluation

lc : Sur stackoverflow et d'autres sites qui utilisent cette méthode, ils traitent presque toujours avec des utilisateurs authentifiés (connectés), car la tâche tentée l'exige.

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

Nous sommes donc de retour à la recherche d'adresses IP, qui a) est assez inutile à l'ère des réseaux cloud et des zombies spambots et b) attrape trop d'innocents étant donné le nombre d'entreprises qui proviennent d'une seule adresse IP (sans parler des problèmes avec FAI IP non statiques et performances potentielles pour essayer de suivre cela).

Oh, et avoir des gens qui nous appellent serait le pire scénario possible. Pouvons-nous les faire vous appeler?

BradC : Les méthodes de Ned Batchelder ont l'air plutôt cool, mais elles sont assez fermement conçues pour vaincre les bots conçus pour un réseau de sites. Notre problème est que les bots sont construits spécifiquement pour vaincre notre site. Certaines de ces méthodes pourraient probablement fonctionner pendant une courte période jusqu'à ce que les scripteurs développent leurs robots pour ignorer le pot de miel, gratter l'écran pour les noms d'étiquettes à proximité au lieu des identifiants de formulaire et utiliser un contrôle de navigateur compatible javascript.

lc à nouveau : "Sauf, bien sûr, le battage médiatique fait partie de votre plan de marketing." Oui, certainement. La surprise du moment où l'article apparaît, ainsi que l'excitation si vous parvenez à en obtenir un sont probablement autant ou plus importantes que la merde que vous finissez par obtenir. Tout ce qui élimine le premier arrivé / premier servi est préjudiciable au plaisir de «gagner» la merde.

novatrust : Et pour ma part, je souhaite la bienvenue à nos nouveaux suzerains de bots. En fait, nous proposons des flux RSS pour permettre aux applications tierces de scanner notre site pour obtenir des informations sur le produit, mais pas avant le code HTML du site principal. Si je l'interprète correctement, votre solution aide l'objectif 2 (problèmes de performances) en sacrifiant complètement l'objectif 1 et en démissionnant simplement du fait que les bots achèteront la majeure partie de la merde. J'ai voté contre votre réponse, car votre pessimisme du dernier paragraphe me semble juste. Il ne semble pas y avoir de solution miracle ici.

Le reste des réponses repose généralement sur le suivi IP, qui, encore une fois, semble à la fois inutile (avec des réseaux de zombies / zombies / cloud) et préjudiciable (attrapant de nombreux innocents qui viennent de destinations de même IP).

D'autres approches / idées? Mes développeurs n'arrêtent pas de dire "faisons simplement CAPTCHA" mais j'espère qu'il y a des méthodes moins intrusives pour tous les humains réels qui veulent une partie de notre merde.

Question d'origine

Disons que vous vendez quelque chose à bas prix qui a une valeur perçue très élevée, et que vous avez un montant très limité. Personne ne sait exactement quand vous vendrez cet article. Et plus d'un million de personnes viennent régulièrement voir ce que vous vendez.

Vous vous retrouvez avec des scripteurs et des robots qui tentent par programmation [a] de savoir quand vous vendez ledit article, et [b] assurez-vous qu'ils sont parmi les premiers à l'acheter. Cela craint pour deux raisons:

1. Votre site est critiqué par des non-humains, ce qui ralentit tout pour tout le monde.
2. Les scénaristes finissent par «gagner» le produit, ce qui fait que les habitués se sentent trompés.

Une solution apparemment évidente consiste à créer des cerceaux pour que vos utilisateurs puissent les parcourir avant de passer leur commande, mais cela pose au moins trois problèmes:

• L'expérience utilisateur craint pour les humains, car ils doivent déchiffrer CAPTCHA, choisir le chat ou résoudre un problème mathématique.
• Si l'avantage perçu est suffisamment élevé et que la foule est suffisamment nombreuse, certains groupes trouveront leur chemin dans n'importe quel ajustement, conduisant à une course aux armements. (Cela est particulièrement vrai plus le réglage est simple; formulaire de `` commentaires '' caché, réorganisation des éléments du formulaire, mauvais étiquetage, texte de `` gotcha '' caché tout fonctionnera une fois et devra ensuite être modifié pour lutter contre le ciblage de ce formulaire spécifique .)
• Même si les scripteurs ne peuvent pas `` résoudre '' votre tweak, cela ne les empêche pas de claquer votre page d'accueil, puis de sonner l'alarme pour que le scripteur remplisse la commande, manuellement. Étant donné qu'ils tirent parti de la résolution de [a], ils gagneront probablement toujours [b] car ils seront les premiers humains à atteindre la page de commande. En outre, 1. se produit toujours, provoquant des erreurs de serveur et une baisse des performances pour tout le monde.

Une autre solution consiste à surveiller les adresses IP qui frappent trop souvent, à les bloquer du pare-feu ou à les empêcher de passer une commande. Cela pourrait résoudre 2. et empêcher [b], mais les performances atteintes lors de l'analyse des adresses IP sont massives et causeraient probablement plus de problèmes comme 1. que les scripteurs ne provoquaient d'eux-mêmes. De plus, la possibilité de mise en réseau cloud et de zombies spambots rend la vérification IP assez inutile.

Une troisième idée, obligeant le bon de commande à être chargé pendant un certain temps (disons, une demi-seconde) ralentirait potentiellement la progression des commandes rapides, mais encore une fois, les scripteurs seraient toujours les premiers à entrer, à n'importe quelle vitesse qui ne nuirait pas à utilisateurs réels.

Buts

1. Vendez l'objet à des humains sans script.
2. Gardez le site en cours d'exécution à une vitesse non ralentie par les bots.
3. Ne dérangez pas les utilisateurs «normaux» avec des tâches à accomplir pour prouver qu'ils sont humains.

Que diriez-vous d'implémenter quelque chose comme SO le fait avec les CAPTCHA?

Si vous utilisez le site normalement, vous n'en verrez probablement jamais. S'il vous arrive de recharger la même page trop souvent, de poster des commentaires successifs trop rapidement ou autre chose qui déclenche une alarme, faites-leur prouver qu'ils sont humains. Dans votre cas, ce serait probablement des rechargements constants de la même page, en suivant rapidement chaque lien d'une page, ou en remplissant un formulaire de commande trop rapidement pour être humain.

S'ils échouent à la vérification x fois de suite (disons, 2 ou 3), donnez à cette IP un délai d'expiration ou une autre mesure de ce type. Ensuite, à la fin du délai d'attente, remettez-les à nouveau dans le chèque.

Étant donné que des utilisateurs non enregistrés accèdent au site, vous ne disposez que d'adresses IP pour continuer. Vous pouvez émettre des sessions sur chaque navigateur et suivre de cette façon si vous le souhaitez. Et, bien sûr, lancez une vérification humaine si trop de sessions sont (recréées) successivement (au cas où un bot continue de supprimer le cookie).

Pour attraper trop d'innocents, vous pouvez afficher une clause de non-responsabilité sur la page de vérification humaine: "Cette page peut également apparaître si trop d'utilisateurs anonymes consultent notre site au même endroit. Nous vous encourageons à vous inscrire ou à vous connecter pour éviter cette." (Ajustez la formulation de manière appropriée.)

En outre, quelles sont les chances que X personnes chargent les mêmes pages en même temps à partir d'une adresse IP? S'ils sont élevés, vous avez peut-être besoin d'un mécanisme de déclenchement différent pour votre alarme de bot.

Modifier: Une autre option est de les bloquer trop souvent et si vous êtes sûr de la demande du produit, de les bloquer et de les appeler personnellement pour supprimer le blocage.

Faire appeler les gens semble être une mesure insensée, mais cela garantit qu'il y a un humain quelque part derrière l'ordinateur . La clé est d'avoir le bloc uniquement en place pour une condition qui ne devrait presque jamais se produire sauf s'il s'agit d'un bot (par exemple, échouer la vérification plusieurs fois de suite). Ensuite, il FORCE l'interaction humaine - pour décrocher le téléphone.

En réponse au commentaire de me faire appeler, il y a évidemment ce compromis ici. Êtes-vous suffisamment inquiet de vous assurer que vos utilisateurs sont humains pour accepter quelques appels téléphoniques lorsqu'ils sont en vente? Si j'étais tellement préoccupé par un produit qui parvienne aux utilisateurs humains, je devrais prendre cette décision, sacrifiant peut-être un (petit) peu de mon temps dans le processus.

Comme il semble que vous soyez déterminé à ne pas laisser les bots prendre le dessus / claquer votre site, je pense que le téléphone peut être une bonne option. Comme je ne tire aucun profit de votre produit, je n'ai aucun intérêt à recevoir ces appels. Si vous partagiez une partie de ces bénéfices, je pourrais être intéressé. Comme il s'agit de votre produit, vous devez décider combien vous vous souciez et mettre en œuvre en conséquence.

Les autres façons de libérer le bloc ne sont tout simplement pas aussi efficaces: un délai d'attente (mais ils pourraient refermer votre site après, rinçage-répétition), un long délai (si c'était vraiment un humain essayant d'acheter votre produit, ils seraient SOL et punis pour avoir échoué la vérification), e-mail (facilement fait par les bots), fax (même) ou courrier postal (prend trop de temps).

Vous pouvez, bien sûr, augmenter la période de temporisation par IP à chaque fois qu'ils obtiennent une temporisation. Assurez-vous simplement que vous ne punissez pas les vrais humains par inadvertance.

Vous devez trouver un moyen pour que les robots achètent des choses qui sont massivement trop chères: écrou à oreilles 12 mm: 20 $. Voyez combien de bots s'enclenchent avant que les scénaristes décident que vous les jouez.

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

Ma solution serait de rendre le grattage d'écran sans valeur en mettant un délai d'environ 10 minutes pour les robots et les scripts.

Voici comment je le ferais:

• Connectez-vous et identifiez les frappeurs répétés.

Vous n'avez pas besoin d'enregistrer chaque adresse IP à chaque hit. Suivez seulement un sur 20 coups environ. Un récidiviste apparaîtra toujours dans un suivi occasionnel aléatoire.

• Gardez un cache de votre page d'environ 10 minutes plus tôt.

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

Ils ne sauront pas immédiatement qu'ils obtiennent un ancien site. Ils pourront le gratter, et tout, mais ils ne gagneront plus aucune course, car les "vrais gens" auront 10 minutes d'avance.

Avantages:

• Pas de soucis ni de problèmes pour les utilisateurs (comme CAPTCHA).
• Implémenté entièrement côté serveur. (pas de recours à Javascript / Flash)
• Servir une page plus ancienne et mise en cache devrait être moins gourmande en performances qu'une page en direct. Vous pouvez en fait diminuer la charge sur vos serveurs de cette façon!

Désavantages

• Nécessite le suivi de certaines adresses IP
• Nécessite de conserver et de maintenir un cache des pages plus anciennes.

Qu'est-ce que tu penses?

Jetez un œil à cet article de ned Batchelder ici . Son article traite de l'arrêt des spambots, mais les mêmes techniques pourraient facilement s'appliquer à votre site.

Plutôt que d'arrêter les bots en faisant en sorte que les gens s'identifient, nous pouvons arrêter les bots en les empêchant de réussir leur publication ou en les faisant s'identifier par inadvertance comme des bots. Cela supprime la charge des personnes et laisse le formulaire de commentaire exempt de mesures anti-spam visibles.

Cette technique est la façon dont j'empêche les spambots sur ce site. Ça marche. La méthode décrite ici ne regarde pas du tout le contenu.

Quelques autres idées:

• Créez un mécanisme officiel de notification automatique (flux RSS? Twitter?) Auquel les gens peuvent s'abonner lorsque votre produit est en vente. Cela réduit la nécessité pour les gens de créer des scripts.
• Modifiez votre technique d'obscurcissement juste avant la mise en vente d'un nouvel article. Donc, même si les scénaristes 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 les méthodes pour empêcher l'achat automatisé d'articles en empêchant un BOT de parcourir les formulaires pour soumettre une commande. Ses techniques ne seraient pas utiles pour empêcher les bots de gratter l'écran de la page d'accueil afin de déterminer quand un Bandoleer of Carrots sera mis en vente. Je ne suis pas sûr d'empêcher CELA est vraiment possible.

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 le SPINNER est la raison pour laquelle j'ai mentionné son article. Désolé, je n'ai pas précisé cela dans mon message d'origine:

Le spinner est un champ caché utilisé pour plusieurs choses: il hache ensemble un certain nombre de valeurs qui empêchent la falsification et les relectures, et est utilisé pour masquer les noms de champ. Le spinner est un hachage MD5 de:

• L'horodatage,
• L'adresse IP du client,
• L'ID d'entrée de l'entrée de blog commentée, et
• Un secret.

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

Modifiez la valeur "secrète" utilisée dans le cadre du hachage chaque fois qu'un nouvel article est mis en vente. Cela signifie que si quelqu'un va concevoir un BOT pour acheter automatiquement des articles, cela ne fonctionnera que jusqu'à ce que l'article suivant soit en vente !!

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 est résolu!

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

• Utilisez des classes CSS (randomisées bien sûr) pour définir les champs ou un élément conteneur à afficher: aucun.
• Colorez les champs de la même manière (ou très similaires à) l'arrière-plan de la page.
• Utilisez le positionnement pour déplacer un champ hors de la zone visible de la page.
• Rendre un élément trop petit pour afficher le champ de pot de miel contenu.
• Laissez les champs visibles, mais utilisez le positionnement pour les couvrir d'un élément d'obscurcissement.
• Utilisez Javascript pour effectuer l'une de ces modifications, nécessitant qu'un bot ait un moteur Javascript complet.
• Laissez les pots de miel affichés comme les autres champs, mais dites aux gens de ne rien y entrer.

Je suppose que mon idée globale est de CHANGER LE DESIGN DE LA FORME lorsque chaque nouvel article est en vente. Ou au MOINS, changez-le quand un nouveau BOC est en vente.

Quel est quoi, quelques fois / mois?

Si vous acceptez cette réponse, m'indiquerez-vous quand la prochaine est prévue? :)

Q: Comment empêcheriez-vous les scripteurs de claquer votre site des centaines de fois par seconde?
R: Non. Il n'existe aucun moyen d' empêcher ce comportement par des agents externes.

Vous pourriez utiliser une vaste gamme de technologies pour analyser les demandes entrantes et tenter heuristement de déterminer qui est ou non humain ... mais cela échouerait. Finalement, sinon immédiatement.

La seule solution viable à long terme consiste à changer le jeu afin que le site ne soit pas compatible avec les bots ou qu'il soit moins attrayant pour les scripteurs.

Comment tu fais ça? Eh bien, c'est une question différente! ;-)

...

OK, certaines options ont été données (et rejetées) ci-dessus. Je ne connais pas intimement votre site, ne l'ayant consulté qu'une seule fois, mais comme les gens peuvent lire du texte dans des images et que les robots ne peuvent pas facilement le faire, changez l'annonce pour qu'elle soit une image. Pas un CAPTCHA , juste une image -

• générer l'image (mise en cache bien sûr) lorsque la page est demandée
• garder le nom de la source d'image le même, afin que cela ne trahisse pas le jeu
• la plupart du temps, l'image contiendra du texte ordinaire et sera alignée pour apparaître comme faisant partie de la page HTML en ligne
• lorsque le jeu est activé, l'image se transforme en texte d'annonce
• le texte de l'annonce révèle une URL et / ou un code qui doivent être saisis manuellement pour acquérir le prix. CAPTCHA le code si vous le souhaitez, mais ce n'est probablement pas nécessaire.
• pour plus de sécurité, le code peut être un jeton unique généré spécifiquement pour la demande / IP / agent, de sorte que les demandes 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 bloc unique) si la génération à la demande est trop éprouvante.

Exécutez des contre-la-montre de personnes réelles qui répondent à cela, et ignorez ('oups, une erreur s'est produite, désolé! Veuillez réessayer') des réponses plus rapides que (disons) la moitié de ce temps. Cet événement devrait également déclencher une alerte pour les développeurs qu'au moins un bot a compris le code / jeu, il est donc temps de changer le code / jeu.

Continuez à changer le jeu périodiquement de toute façon, même si aucun bot ne le déclenche, juste pour perdre le temps des scripteurs. Finalement, les scripteurs devraient se lasser du jeu et aller ailleurs ... nous espérons ;-)

Une dernière suggestion: lorsqu'une demande pour votre page principale arrive, mettez-la dans une file d'attente et répondez aux demandes dans l'ordre dans un processus distinct (vous devrez peut-être pirater / étendre le serveur Web pour ce faire, mais ce sera probablement digne d'intérêt). Si une autre demande du même IP / agent arrive alors que la première demande est dans la file d'attente, ignorez-la. Cela devrait automatiquement éliminer la charge des robots.

EDIT: une autre option, outre l'utilisation d'images, est d'utiliser javascript pour remplir le texte d'achat / non-achat; les robots interprètent rarement javascript, donc ils ne le verront pas

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

Découvrez les données que les robots analysent. Donnez-leur les données qu'ils recherchent lorsque vous ne vendez PAS la merde. Faites-le d'une manière qui ne dérange pas ou ne déroute pas les utilisateurs humains. Lorsque les bots déclenchent la phase deux, ils se connectent et remplissent le formulaire pour acheter 100 $ roombas au lieu de BOC. Bien sûr, cela suppose que les robots ne sont pas particulièrement robustes.

Une autre idée est de mettre en œuvre des baisses de prix aléatoires au cours de la période de vente du sac ou de la merde. Qui achèterait un sac aléatoire de merde pour 150 $ lorsque vous dites clairement qu'il ne vaut que 20 $? Personne, sauf des robots trop zélés. Mais 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 faire en sorte que leurs erreurs deviennent très coûteuses pour eux (et de les faire payer pour les combattre).

Tout cela suppose que vous voulez faire chier certains seigneurs de robots, ce qui n'est peut-être pas conseillé à 100%.

Donc, le problème semble vraiment être: les bots veulent leur "bag 'o crap" car il a une valeur perçue élevée à un prix perçu faible. Vous proposez parfois cet article et les robots se cachent, attendant de voir s'il est disponible, puis ils achètent l'article.

Comme il semble que les propriétaires de bots réalisent un bénéfice (ou potentiellement réalisent un bénéfice), l'astuce consiste à rendre cela non rentable pour eux en les encourageant à acheter la merde.

Tout d'abord, offrez toujours le "bag 'o crap".

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

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

C'est simple, non?

Vous aurez besoin d'un permanent "pourquoi nos conneries sont-elles parfois des conneries?" lien à côté de l'offre pour expliquer aux humains ce qui se passe.

Lorsque le bot voit qu'il y a de la merde et que la merde est automatiquement achetée, le destinataire va être terriblement contrarié d'avoir payé 10 $ pour un cure-dent cassé. Et puis un sac poubelle vide. Et puis un peu de saleté du bas de votre chaussure.

S'ils achètent assez de cette merde dans un laps de temps relativement court (et que vous avez de nombreux avertissements partout expliquant pourquoi vous faites cela), ils vont perdre un "sac d'argent" sur votre " bag 'o crap ". Même une intervention humaine de leur part (vérification pour s'assurer 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 rien qui a été dans la rotation depuis trop peu de temps, mais cela signifie que les humains achèteront la non-merde.

Heck, vos clients réguliers peuvent être tellement amusés que vous pouvez transformer cela en une énorme victoire marketing. Commencez à publier la quantité de carpes "merdiques" vendues. Les gens reviendront juste pour voir à quel point les robots ont été mordus.

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

1. Vendez l'objet à des humains sans script.

2. Gardez le site en cours d'exécution à une vitesse non ralentie par les bots.

3. Ne dérangez pas les utilisateurs «normaux» avec des tâches à accomplir pour prouver qu'ils sont humains.

Vous ne voulez probablement pas entendre cela, mais # 1 et # 3 s'excluent mutuellement.

Eh bien, personne ne sait que tu es un bot non plus. Il n'y a aucun moyen programmatique de dire s'il y a ou non un humain à l'autre extrémité de la connexion sans exiger de la personne qu'elle fasse quelque chose. Empêcher les scripts / bots de faire des choses sur le Web est la raison pour laquelle les CAPTCHA ont été inventés. Ce n'est pas comme s'il s'agissait d'un nouveau problème qui n'a pas nécessité beaucoup d'efforts. S'il y avait une meilleure façon de le faire, une qui n'impliquait pas les tracas aux vrais utilisateurs qu'un CAPTCHA fait, tout le monde l'utiliserait déjà.

Je pense que vous devez faire face au fait que si vous voulez garder les robots hors de votre page de commande, un bon CAPTCHA est le seul moyen de le faire. Si la demande pour votre merde aléatoire est suffisamment élevée pour que les gens soient prêts à aller aussi loin pour l'obtenir, les utilisateurs légitimes ne seront pas rebutés par un CAPTCHA.

La méthode que Woot utilise pour lutter contre ce problème change le jeu - littéralement. Lorsqu'ils présentent un article extraordinairement souhaitable à la vente, ils incitent les utilisateurs à jouer à un jeu vidéo afin de le commander.

Non seulement cela combat avec succès les bots (ils 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.

Il se vend toujours très rapidement, mais je pense que la solution est bonne - réévaluer le problème et changer les paramètres a conduit à une stratégie réussie où les solutions strictement techniques n'existaient tout simplement pas.

Tout votre modèle d'entreprise est basé sur le «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 font du 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 changer l'expérience de commande pour les vrais utilisateurs.

Disons que vous implémentez toutes ces tactiques. Si je décide que c'est important, j'obtiendrai simplement 100 personnes pour travailler avec moi, nous créerons un logiciel pour travailler sur nos 100 ordinateurs distincts et frapperons votre site 20 fois par seconde (5 secondes entre les accès pour chaque utilisateur / cookie / compte / adresse IP).

Vous avez deux étapes:

1. Regarder la première page
2. Commande

Vous ne pouvez pas mettre un captcha bloquant # 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 regarde, chronométré ensemble pour que nous obtenions environ 20 chèques par seconde, et quiconque voit le changement alerte d'abord tous les autres (automatiquement), qui chargera à nouveau la première page, suivra le lien de commande et effectuera la transaction ( ce qui peut également se produire automatiquement, à moins que vous n'implémentiez captcha et le changiez pour chaque wootoff / boc).

Vous pouvez placer un captcha devant le n ° 2, et pendant que vous détestez le faire, cela peut être le seul moyen de vous assurer que même si les robots regardent la première page, les vrais utilisateurs obtiennent les produits.

Mais même avec captcha, mon petit groupe de 100 aurait toujours un avantage significatif en tant que premier moteur - et il n'y a aucun moyen de savoir que nous ne sommes pas des humains. Si vous commencez à chronométrer nos accès, nous ajouterions simplement un peu de gigue. Nous pourrions sélectionner au hasard quel ordinateur devait être actualisé afin que l'ordre des accès change constamment - mais ressemble toujours assez à un humain.

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

Vous devez avoir un pare-feu adaptatif qui surveillera les demandes et si quelqu'un fait la chose stupide évidente - rafraîchir plus d'une fois par seconde sur la même IP, puis utiliser des tactiques pour les ralentir (supprimer des paquets, renvoyer des refus ou 500 erreurs, etc.) ).

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

Deuxièmement, rendez le serveur incroyablement rapide.

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 jouer avec la pile TCP / IP, mais vous devrez peut-être développer un serveur personnalisé très, très, très rapide conçu spécialement pour corréler les connexions utilisateur et réagir de manière appropriée aux diverses attaques.

Apache, lighthttpd, etc. sont tous parfaits pour être flexibles, mais vous gérez un site Web à but unique, et vous devez vraiment être en mesure de faire plus que ce que les serveurs actuels sont capables de faire (à la fois dans la gestion du trafic et dans la lutte appropriée contre les bots ).

En servant une page Web largement statique (mises à jour toutes les 30 secondes environ) sur un serveur personnalisé, vous ne devriez pas seulement ê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 la mémoire dans le tampon TCP / IP) mais il vous donnera également accès à des mesures qui pourraient vous aider à ralentir les bots. Par exemple, en corrélant les adresses IP, vous pouvez simplement bloquer plus d'une connexion par seconde par IP. Les humains ne peuvent pas aller plus vite que cela, et même les personnes utilisant la même adresse IP NAT ne seront que rarement bloquées. Vous voudriez faire un blocage lent - laissez la connexion tranquille pendant une seconde complète avant de terminer officiellement la session. Cela peut alimenter un pare-feu pour donner des blocages à plus long terme aux délinquants particulièrement flagrants.

Mais la réalité est que, quoi que vous fassiez, il n'y a aucun moyen de distinguer un humain d'un bot lorsque le bot est construit sur mesure par un humain dans un seul but. Le bot n'est qu'un proxy pour l'humain.

Conclusion

À la fin de la journée, vous ne pouvez pas distinguer un humain et un ordinateur pour avoir regardé la première page. Vous pouvez arrêter les bots à l'étape de la commande, mais les utilisateurs de bots ont toujours un avantage de premier ordre et vous avez encore une énorme charge à gérer.

Vous pouvez ajouter des blocs pour les robots simples, ce qui augmentera la barre et réduira le nombre de personnes qui s'en soucient. C'est peut-être suffisant.

Mais sans changer votre modèle de base, vous n'avez pas de chance. Le mieux que vous puissiez faire est de prendre soin des cas simples, de rendre le serveur si rapide que les utilisateurs réguliers ne le remarquent pas et de vendre autant d'articles que même si vous avez quelques millions de robots, autant d'utilisateurs réguliers que vous le souhaitez les obtiendront .

Vous pouvez envisager de configurer un pot de miel et de marquer les comptes d'utilisateurs en tant qu'utilisateurs de robots, mais cela aura un énorme jeu négatif de la communauté.

Chaque fois que je pense à un "bien, qu'en est-il de faire cela ..." Je peux toujours le contrer avec une stratégie de bot appropriée.

Même si vous faites de la première page un captcha pour accéder à la page de commande ("Le bouton de commande de cet article est bleu avec des étincelles roses, quelque part sur cette page"), les bots ouvriront simplement tous les liens sur la page et utiliseront celui qui vient de retour avec une page de commande. Ce n'est tout simplement pas un moyen de gagner cela.

Rendez les serveurs rapides, mettez un reCaptcha (le seul que j'ai trouvé qui ne puisse pas être facilement trompé, mais c'est probablement beaucoup trop lent pour votre application) sur la page de commande, et réfléchissez aux moyens de changer légèrement le modèle afin les utilisateurs réguliers ont autant de chances que les utilisateurs de robots.

-Adam

Avis de non-responsabilité: cette réponse n'est pas liée à la programmation. Cependant, il essaie d'abord d'attaquer la raison des scripts.

Une autre idée est que si vous avez vraiment une quantité limitée à vendre, pourquoi ne la changez-vous pas à partir d'une méthode du premier arrivé, premier servi? Sauf, bien sûr, le battage médiatique fait partie de votre plan de 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 commande (système de précommande) - Certains scripts peuvent toujours se retrouver à l'avant de la file d'attente, mais il est probablement plus rapide de saisir manuellement les informations.

• un système de tombola (tous ceux qui essaient d'en commander un sont entrés dans le système) - De cette façon, les personnes avec les scripts ont juste les mêmes chances que celles qui n'en ont pas.

• une file d'attente prioritaire urgente - S'il y a vraiment une valeur perçue élevée, les gens peuvent être prêts à 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ères (crédit à David Schmitt pour celui-ci, les commentaires sont les miens) - Les gens peuvent toujours utiliser des scripts pour se faufiler à la dernière minute, mais non seulement cela change la structure des prix, mais les gens s'attendent à se battre avec d'autres . Vous pouvez également faire des choses pour limiter le nombre d'enchères dans une période donnée, inciter les gens à téléphoner à l'avance pour un code d'autorisation, etc.

Peu importe à quel point les nazis pensaient que leurs communications étaient sécuritaires, les alliés rompaient souvent leurs messages. Peu importe comment vous essayez d'empêcher les robots d'utiliser votre site, les propriétaires de robots 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 bots d'utiliser votre site
• N'allez pas chercher une solution qui fonctionne immédiatement, jouez au long jeu

Gardez à l'esprit que peu importe que le client de votre site soit un humain ou un bot, les deux ne sont que des clients payants; mais l'un a un avantage injuste sur l'autre. Certains utilisateurs sans grande vie sociale (ermites) peuvent être aussi ennuyeux pour les autres utilisateurs de votre site que les bots.

Enregistrez l'heure à laquelle vous publiez une offre et l'heure à laquelle un compte décide de l'acheter.

Cela vous donne un enregistrement de la rapidité avec laquelle le client achète des choses.

Variez l'heure à laquelle vous publiez des offres.

Par exemple, ayez une fenêtre de 3 heures commençant à une heure obscure de la journée (minuit?) Seuls les bots et les ermites rafraîchiront constamment une page pendant 3 heures juste pour obtenir une commande en quelques secondes. Ne modifiez jamais l'heure de base, uniquement la taille de la fenêtre.

Avec le temps, une image émergera.

01: Vous pouvez voir quels comptes achètent régulièrement des produits en quelques secondes après leur mise en ligne. Suggérer qu'ils pourraient être des robots.

02: Vous pouvez également regarder la fenêtre de temps utilisée pour les offres, si la fenêtre est de 1 heure, certains des premiers acheteurs seront des humains. Cependant, un humain se rafraîchit rarement pendant 4 heures. Si le temps écoulé est assez cohérent entre la publication / l'achat quelle que soit la durée de la fenêtre, c'est un bot. Si le temps de publication / achat est court pour les petites fenêtres et s'allonge pour les grandes fenêtres, c'est un ermite!

Maintenant, au lieu d'empêcher les bots d'utiliser votre site, vous disposez de suffisamment d'informations pour vous dire quels comptes sont certainement utilisés par les bots et quels comptes sont susceptibles d'être utilisés par les ermites. Ce que vous faites avec ces informations dépend de vous, mais vous pouvez certainement les utiliser pour rendre votre site plus équitable pour les personnes qui ont une vie.

Je pense que l'interdiction des comptes de robots serait inutile, cela reviendrait à téléphoner à Hitler et à 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 propriétaires de comptes ne réaliseront pas. Voyons voir si je peux imaginer quoi que ce soit .....

Traiter les commandes dans une file d'attente:

Lorsque le client passe une commande, il reçoit immédiatement un e-mail de confirmation lui indiquant que sa commande est placée dans une file d'attente et sera informé de son traitement. J'expérimente ce genre de chose avec une commande / expédition 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 e-mail 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é envoyée.

Les utilisateurs pensent qu'ils sont dans une file d'attente équitable. Traitez votre file d'attente toutes les 1 heure afin que les utilisateurs normaux connaissent également une file d'attente, afin de ne pas éveiller les soupçons. Traitez les commandes des comptes bot et ermite uniquement une fois qu'ils ont été dans la file d'attente pour le "temps de commande humain moyen + x heures". Réduire efficacement les robots aux humains.

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

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

Il existe des proxys et des botnets pour vaincre les contrôles IP. Il existe des scripts de lecture de captcha qui sont extrêmement bons. Il y a même des équipes de travailleurs en Inde qui battent les captchas pour un petit prix. Toute solution que vous pouvez trouver peut être raisonnablement rejetée. 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.

Pour ce faire, nous utilisons actuellement la dernière génération d'équilibreurs de charge BigIP de F5. Le BigIP possède des fonctionnalités avancées de gestion du trafic qui peuvent identifier les grattoirs et les robots en fonction de la fréquence et des modèles d'utilisation, même parmi un ensemble de sources derrière une seule adresse IP. 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 votre code d'application.

Tout d'abord, permettez-moi de récapituler ce que nous devons faire ici. Je me rends compte que je paraphrase simplement la question initiale, mais il est important que nous obtenions ce 100% directement, car il y a beaucoup de bonnes suggestions qui obtiennent 2 ou 3 sur 4, mais comme je vais le démontrer, vous aurez besoin d'un approche multidimensionnelle pour couvrir toutes les exigences.

Exigence 1: se débarrasser du «claquement de bots»:

Le «claquement» rapide de votre page d'accueil nuit aux performances de votre site et est au cœur du problème. Le `` claquement '' provient à la fois des bots à IP unique et - soi-disant - des botnets également. Nous voulons nous débarrasser des deux.

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

Nous pourrions régler la situation du bot assez efficacement en mettant en œuvre une procédure de vérification désagréable comme téléphoner à un opérateur humain, résoudre un tas de CAPTCHA, ou similaire, mais ce serait comme forcer chaque passager d'avion innocent à sauter à travers des cerceaux de sécurité fous juste pour la mince chance d'attraper le plus stupide des terroristes. Oh, attendez - c'est ce que nous faisons. Mais voyons si nous ne pouvons pas faire ça sur woot.com.

Exigence 3: éviter la «course aux armements»:

Comme vous le mentionnez, vous ne voulez pas vous laisser entraîner dans la course aux armements de spambots. Vous ne pouvez donc pas utiliser de simples ajustements comme des champs de formulaire cachés ou brouillés, des questions mathématiques, etc., car ce sont essentiellement des mesures d'obscurité qui peuvent être trivialement détectées automatiquement et contournées.

Exigence 4: déjouer les robots «d'alarme»:

Cela peut être le plus difficile de vos besoins. Même si nous pouvons faire un défi de vérification humaine efficace, les bots pourraient toujours interroger votre page d'accueil et alerter le scripteur quand il y a une nouvelle offre. Nous voulons également rendre ces robots irréalisables. Il s'agit d'une version plus forte de la première exigence, car non seulement les bots ne peuvent pas émettre de demandes de tir rapide préjudiciables aux performances, mais ils ne peuvent même pas émettre suffisamment de demandes répétées pour envoyer une `` alarme '' au scripteur à temps pour gagner. l'offre.

D'accord, voyons donc si nous pouvons répondre aux quatre exigences. Premièrement, comme je l'ai mentionné, aucune mesure ne fera l'affaire. Vous devrez combiner quelques astuces pour y parvenir, et vous devrez avaler deux désagréments:

1. Un petit nombre d'utilisateurs devront sauter à travers les cerceaux
2. Un petit nombre d'utilisateurs ne pourront pas bénéficier des offres spéciales

Je me rends compte que ce sont ennuyeux, mais si nous pouvons rendre le «petit» nombre suffisamment petit , j'espère que vous conviendrez que les points positifs l'emportent sur les points négatifs.

Première mesure: limitation basée sur 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 de se rafraîchir 600 fois par seconde (ou quelque chose), vous arrêtez de répondre et lui dites de le refroidir. En fait, vous étranglez probablement ses demandes beaucoup plus tôt que cela, mais vous avez l'idée. De cette façon, un bot connecté sera banni / limité dès qu'il commencera à interroger votre site. C'est la partie facile. Les bots non authentifiés sont notre vrai problème, ainsi de suite pour eux:

Deuxième mesure: une certaine forme de limitation IP, comme suggéré par presque tout le monde:

Quoi qu'il en soit, vous devrez effectuer une limitation basée sur IP pour contrecarrer le «claquement du bot». Comme il vous semble important de permettre aux visiteurs non authentifiés (non connectés) pour obtenir les offres spéciales, vous avez seulement les adresses IP à passer d' abord, et bien qu'ils ne sont pas parfaits, ils ne le travail contre les robots IP unique. Les botnets sont une bête différente, mais j'y reviendrai. Pour l'instant, nous allons faire quelques étranglements simples pour vaincre les bots à IP unique à tir rapide.

L'atteinte des performances est négligeable si vous exécutez la vérification IP avant tout autre traitement, utilisez un serveur proxy pour la logique de limitation et stockez les IP dans une arborescence optimisée pour la recherche memcached.

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

Avec les robots à une seule adresse IP à tir rapide, nous devons encore nous attaquer aux robots à une seule IP lents, c'est-à-dire. les bots qui sont spécifiquement ajustés pour «voler sous le radar» en espaçant les requêtes légèrement plus loin que la limitation ne les empêche.

Pour rendre instantanément inutiles les bots à IP unique lents, utilisez simplement la stratégie suggérée par abelenky: servir des pages mises en cache de 10 minutes à toutes les adresses IP qui ont été repérées au cours des dernières 24 heures (ou plus). De cette façon, chaque IP obtient une `` chance '' par jour / heure / semaine (selon la période que vous choisissez), et il n'y aura pas de 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 qu'elle fait également échouer les «bots d'alarme», tant qu'ils ne proviennent pas d'un botnet.

(Je sais que vous préféreriez probablement que les vrais utilisateurs soient autorisés à se rafraîchir encore et encore, mais il n'y a aucun moyen de distinguer un humain de rafraîchissement de spam d'un bot de spam de demande sans CAPTCHA ou similaire)

Quatrième mesure: reCAPTCHA:

Vous avez raison de dire que les CAPTCHA nuisent à l'expérience utilisateur et doivent être évités. Cependant, dans une situation _one_ , ils peuvent être votre meilleur ami: si vous avez conçu un système très restrictif pour contrecarrer les bots, cela - en raison de sa restrictivité - attrape également un certain nombre de faux positifs; puis un CAPTCHA servi en dernier recours permettra aux vrais utilisateurs qui se font prendre de glisser par votre limitation (évitant ainsi les situations DoS ennuyeuses).

Le point idéal, bien sûr, est lorsque TOUS les bots sont pris dans votre filet, alors que très peu d'utilisateurs réels sont gênés par le CAPTCHA.

Si vous, au moment de servir l'offre également des pages mises en cache âgés de 10 minutes, une alternative, en option , CAPTCHA-verified de recyclage de la première page », alors les humains qui vraiment veulent garder rafraîchissante, peut encore le faire sans obtenir la vieille page en cache , mais au prix d'avoir à résoudre un CAPTCHA pour chaque rafraîchissement. C'est une gêne, mais une option juste pour les utilisateurs intransigeants, qui ont tendance à être plus indulgent parce qu'ils savent qu'ils sont le système de jeu pour améliorer leurs chances, et que de meilleures chances ne sont pas gratuits.

Cinquième mesure: merde leurre:

Christopher Mahan avait une idée que j'aimais plutôt, mais j'y mettrais une tournure différente. Chaque fois que vous préparez une nouvelle offre, préparez également deux autres «offres», qu'aucun humain ne choisirait, comme un écrou à oreilles de 12 mm pour 20 $. Lorsque l'offre apparaît sur la première page, mettez les trois «offres» dans la même image, avec des numéros correspondant à chaque offre. Lorsque l'utilisateur / le bot commande réellement l'article, il devra choisir (un bouton radio) l'offre qu'il veut, et comme la plupart des bots devineraient simplement, dans deux cas sur trois, les bots achèteraient sans valeur déchet.

Naturellement, cela ne traite pas des `` robots d'alarme '', et il y a une chance (mince) que quelqu'un puisse construire un bot capable de choisir le bon article. Cependant, le risque d'acheter accidentellement du courrier indésirable devrait obliger les scripteurs à se détourner entièrement des robots entièrement automatisés.

Sixième mesure: étranglement du botnet:

[supprimé]

D'accord ............ J'ai maintenant passé la majeure partie de ma soirée à réfléchir à cela, à essayer différentes approches .... des retards globaux .... des jetons basés sur des cookies .. une file d'attente ... «étranglement étranger» .... Et cela ne fonctionne tout simplement pas. Ce n'est pas le cas. J'ai réalisé que la principale raison pour laquelle vous n'aviez pas encore accepté de réponse était que personne n'avait proposé un moyen de contrecarrer une attaque distribuée / filet de zombies / botnet .... alors je voulais vraiment la casser. Je crois que j'ai craqué le problème du botnet pour l'authentification dans un thread différent , donc j'avais de grands espoirs pour votre problème également. Mais mon approche ne se traduit pas par cela. Vous n'avez que des adresses IP pour passer, et un botnet suffisamment grand ne se révèle dans aucune analyse basée sur les adresses IP.

Alors voilà : ma sixième mesure est nulle. Rien. Zip *: français. À moins que le botnet ne soit petit et / ou assez rapide pour être pris dans l'accélérateur IP habituel, je ne vois aucune mesure efficace contre les botnets qui n'implique pas de vérification humaine explicite telle que CAPTHA. Je suis désolé, mais je pense que la combinaison des cinq mesures ci-dessus est votre meilleur pari. Et vous pourriez probablement faire très bien avec le truc de mise en cache de 10 minutes d'Abelenky seul.

Que diriez-vous d'introduire un retard qui nécessite une interaction humaine, comme une sorte de "jeu CAPTCHA". Par exemple, il pourrait s'agir d'un petit jeu Flash où pendant 30 secondes, ils doivent éclater des boules à carreaux et éviter d'éclater des boules solides (en évitant les problèmes de daltonisme!). Le jeu recevrait une graine de nombre aléatoire et ce que le jeu retransmet au serveur serait les coordonnées et les horodatages des points cliqués, ainsi que la graine utilisée.

Sur le serveur, vous simulez les mécanismes du jeu en utilisant cette graine pour voir si les clics auraient bien fait éclater les balles. S'ils l'ont fait, non seulement ils étaient humains, mais ils ont mis 30 secondes à 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 recommencer.

Il y a quelques autres / meilleures solutions déjà publiées, mais pour être complet, j'ai pensé que je mentionnerais ceci:

Si votre principale préoccupation est la dégradation des performances et que vous envisagez un véritable martèlement , vous êtes en fait confronté à une attaque DoS, et vous devriez probablement essayer de la gérer en conséquence. Une approche courante consiste simplement à supprimer des paquets d'une adresse IP dans le pare-feu après un certain nombre de connexions par seconde / minute / etc. Par exemple, le pare-feu Linux standard, iptables, a une fonction de correspondance d'opération standard «hashlimit», qui pourrait être utilisée pour corréler les demandes de connexion par unité de temps à une adresse IP.

Bien que cette question soit probablement plus appropriée pour le prochain dérivé SO mentionné sur le dernier podcast SO, il n'a pas encore été lancé, donc je suppose que c'est correct de répondre :)

EDIT:
Comme l'a souligné novatrust, il y a toujours des FAI qui n'attribuent PAS d'IP à leurs clients, si bien qu'un client de script d'un tel FAI désactiverait tous les clients de ce FAI.

Écrivez un proxy inverse sur un serveur Apache en face de votre application qui implémente un Tarpit (article Wikipedia) pour punir les bots. Il gérerait simplement une liste d'adresses IP qui se sont connectées au cours des dernières secondes. Vous détectez une rafale de demandes à partir d'une seule adresse IP, puis retardez exponentiellement ces demandes avant de répondre.

Bien sûr, plusieurs humains peuvent provenir de la même adresse IP s'ils sont sur une connexion réseau NAT, mais il est peu probable qu'un humain se soucie de votre temps de réponse allant de 2 ms à 4 ms (ou même 400 ms) alors qu'un bot sera gêné par le retard croissant assez rapidement.

1. Fournissez un flux RSS afin qu'ils ne mangent pas votre bande passante.
2. Lors de l'achat, faites attendre tout le monde jusqu'à 45 secondes ou quelque chose au hasard , selon ce que vous recherchez exactement. Quelles sont exactement vos contraintes de temps?
3. Donnez à chacun une minute pour inscrire son nom dans le dessin, puis sélectionnez des personnes au hasard. Je pense que c'est la manière la plus juste.
4. Surveillez les comptes (inclure des moments dans la session et les stocker?) Et ajoutez des retards aux comptes qui semblent être en dessous du seuil de vitesse humaine. Cela fera au moins que les robots soient programmés pour ralentir et rivaliser avec les humains.

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

Si nous pouvons accepter une prémisse selon laquelle nous pouvons imposer un certain coût à un tout nouveau visiteur Woot sur sa première page (s), je pense avoir une solution possible. Faute d'un meilleur nom, je vais appeler vaguement cette solution "une visite au DMV".

Disons qu'il y a un concessionnaire automobile qui propose chaque jour une nouvelle voiture différente et que certains jours, vous pouvez acheter une voiture de sport exotique pour 5 $ chacun (limite 3), plus des frais de destination de 5 $.

Le hic, c'est que le concessionnaire vous oblige à visiter le concessionnaire et à montrer un permis de conduire valide avant de pouvoir entrer par la porte pour voir quelle voiture est en vente. De plus, vous devez avoir un permis de conduire valide pour effectuer l'achat.

Ainsi, le premier visiteur (appelons-le Bob) chez ce concessionnaire automobile se voit refuser l'entrée et est référé au bureau DMV (qui est idéalement situé juste à côté) pour obtenir un permis de conduire.

Les autres visiteurs avec un permis de conduire valide sont autorisés à entrer, après avoir montré son permis de conduire. Une personne qui se gêne en flânant toute la journée, en harcelant les vendeurs, en saisissant des brochures et en vidant le café et les biscuits gratuits sera finalement refoulée.

Maintenant, revenons à Bob sans la licence - tout ce qu'il a à faire est de supporter une fois la visite au DMV. Après cela, il peut visiter le concessionnaire et acheter des voitures à tout moment, à moins qu'il n'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 à falsifier.

La visite au DMV consiste d'abord à obtenir le formulaire de demande dans la file d'attente «Commencez ici». Bob doit apporter la demande remplie à la fenêtre n ° 1, où le premier des nombreux fonctionnaires hargneux prendra sa demande, la traitera, et si tout est en ordre, tamponner la demande pour la fenêtre et l'envoyer à la fenêtre suivante. Et donc, Bob passe de fenêtres en fenêtres, attendant que chaque étape de sa demande soit acceptée, jusqu'à ce qu'il arrive enfin à la fin et reçoive son permis de conduire.

Il ne sert à rien d'essayer de «court-circuiter» le DMV. Si les formulaires ne sont pas remplis correctement en trois exemplaires, ou si des réponses erronées sont données à n'importe quelle fenêtre, la demande est déchirée et le client malheureux est renvoyé au début.

Fait intéressant, quel que soit le niveau de remplissage ou de vide du bureau, il faut environ le même temps pour être entretenu à chaque fenêtre successive. Même lorsque vous êtes la seule personne en ligne, il semble que le personnel aime vous faire attendre une minute derrière la ligne jaune avant de prononcer "Next!"

Cependant, les choses ne sont pas si terribles au DMV. Pendant que toutes les attentes et le traitement pour obtenir la licence se poursuivent, vous pouvez regarder une infopublicité très divertissante et informative pour le concessionnaire automobile pendant 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 devient nécessaire d'avoir un certain état dans la relation client-serveur qui vous permet de séparer les humains des robots. Vous voulez le faire d'une manière qui ne pénalise pas trop le visiteur humain anonyme (non authentifié).

Cette approche nécessite probablement un traitement côté client AJAX-y. Un tout nouveau visiteur à la fessée reçoit le "Bienvenue nouvel utilisateur!" page pleine de texte et de graphiques qui (par une limitation appropriée côté serveur) prend quelques secondes pour se charger complètement. Pendant que cela se produit (et que le visiteur est probablement occupé à lire les pages d'accueil), son jeton d'identification est lentement assemblé.

Disons, pour discussion, que le jeton (alias "permis de conduire") se compose de 20 morceaux. Pour obtenir chaque morceau successif, le code côté client doit soumettre une demande valide au serveur. Le serveur incorpore un délai délibéré (disons 200 millisecondes), avant d'envoyer le bloc suivant avec le 'tampon' nécessaire pour faire la prochaine demande de bloc (c'est-à-dire les tampons nécessaires pour passer d'une fenêtre DMV à la suivante). En tout, environ 4 secondes doivent s'écouler pour terminer le chunk-challenge-response-chunk-challenge-response -...- chunk-challenge-response-response processus.

À la fin de ce processus, le visiteur dispose d'un jeton qui lui permet d'accéder à la page de description du produit et, à son tour, d'accéder à la page d'achat. Le jeton est un identifiant unique pour chaque visiteur et peut être utilisé pour limiter ses activités.

Côté serveur, vous n'acceptez que les pages vues des clients disposant d'un jeton valide. Ou, s'il est important que tout le monde puisse finalement voir la page, imposez une pénalité de temps sur les demandes auxquelles il manque un jeton valide.

Maintenant, pour que cela soit relativement bénin pour le visiteur humain légitime, t faites en sorte que le processus d'émission de jetons se produise de manière relativement non intrusive en arrière-plan. D'où la nécessité d'une page d'accueil avec une copie et des graphiques divertissants qui sont délibérément légèrement ralentis.

Cette approche force une limitation des robots à utiliser un jeton existant ou à prendre le temps d'installation minimum pour obtenir un nouveau jeton. Bien sûr, cela n'aide pas autant contre les attaques sophistiquées utilisant un réseau distribué de faux visiteurs.

Vous ne pouvez pas totalement empêcher les bots, même avec un captcha. Cependant, vous pouvez faire de la peine à écrire et à maintenir un bot et donc à réduire le nombre. En particulier, en les forçant à mettre à jour quotidiennement leurs robots, vous allez perdre le plus d'intérêt.

Voici quelques idées pour rendre plus difficile l'écriture de bots:

• Nécessite l'exécution d'une fonction javascript. Javascript rend beaucoup plus difficile d'écrire un bot. Peut-être besoin d'un captcha s'ils n'exécutent pas javascript pour permettre aux utilisateurs réels non javascript (minimes).

• Chronométrez les frappes lors de la saisie dans le formulaire (à nouveau via javascript). Si ce n'est pas humain, rejetez-le. C'est une douleur d'imiter la saisie humaine dans un bot.

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

• Écrivez votre code pour réorganiser vos champs quotidiennement (évidemment d'une certaine manière, ce n'est pas aléatoire pour vos utilisateurs). S'ils s'appuient sur l'ordre du champ, cela les déclenchera et forcera à nouveau la maintenance quotidienne de leur code bot.

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

En règle générale, si vous commencez à ne pas les empêcher, mais à les rendre plus efficaces, vous pouvez probablement atteindre l'objectif que vous recherchez.

Tenez un délai de 5 minutes sur toutes les annonces de produits pour les utilisateurs non enregistrés. Les utilisateurs occasionnels ne le remarqueront pas vraiment et les utilisateurs non occasionnels 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 fait un projet pour l'un de mes clients qui analyse les journaux d'accès HTTP toutes les cinq minutes (cela aurait pu être en temps réel, mais il ne le voulait pas pour une raison que je n'ai jamais bien comprise) et crée des règles de pare-feu pour bloquer les connexions de toutes les adresses IP qui génèrent un nombre excessif de demandes, sauf si l'adresse peut ê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. L'activité de pointe se situe dans la plage des mille hits par seconde et il n'y a jamais eu de problème de performances - les pare-feu sont très efficaces pour supprimer des paquets à partir d'adresses sur liste noire.

Et, oui, la technologie DDOS existe certainement, ce qui irait à l'encontre de ce schéma, mais il ne voit pas cela se produire dans le monde réel. Au contraire, il dit que cela a considérablement réduit la charge sur ses serveurs.

Mon approche serait de me concentrer sur des solutions non technologiques (sinon vous entrez dans une course aux armements que vous perdrez, ou au moins dépenserez beaucoup de temps et d'argent). Je me concentrerais sur les pièces de facturation / expédition - vous pouvez trouver des robots en trouvant plusieurs livraisons à la même adresse ou en facturant plusieurs frais à un seul mode de paiement. Vous pouvez même le faire sur plusieurs éléments sur plusieurs semaines, donc si un utilisateur a obtenu un élément précédent (en répondant très rapidement), il peut lui être attribué une sorte de "handicap" cette fois-ci.

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

La plupart des solutions purement techniques ont déjà été proposées. Je proposerai donc une autre vision du problème.

Si je comprends bien, les bots sont mis en place par des gens qui essaient vraiment d'acheter les sacs que vous vendez. Le problème est -

1. D'autres personnes, qui n'utilisent pas de robots, méritent une chance d'acheter, et vous offrez une quantité limitée de sacs.
2. Vous voulez attirer des humains sur votre site et simplement vendre les sacs.

Au lieu d'essayer d'éviter les bots, vous pouvez permettre aux acheteurs potentiels de sacs de s'abonner à un e-mail, voire à une mise à jour par SMS, pour être averti lorsqu'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 vont acheter, ils sont sur votre site, vous pouvez leur montrer tout ce que vous voulez dans des bannières latérales ou autre chose. Ceux qui dirigent les robots préféreront simplement s'inscrire à votre service de notification.

Les coureurs de bots peuvent toujours exécuter des bots sur votre notification pour terminer l'achat plus rapidement. Certaines solutions peuvent offrir un achat en un clic.

Soit dit en passant, vous avez mentionné que vos utilisateurs ne sont pas enregistrés, mais il semble que ceux qui achètent ces sacs ne sont pas des acheteurs aléatoires, mais des gens qui attendent ces ventes avec impatience. À ce titre, ils pourraient être disposés à s'inscrire pour obtenir un avantage en essayant de «gagner» un sac.

Essentiellement, ce que je suggère, c'est d'essayer de considérer le problème comme un problème social plutôt que technique.

Asaf

Agents utilisateurs bloquant le temps qui font autant de requêtes par minute. Par exemple, si quelqu'un demande une page exactement toutes les 5 secondes pendant 10 minutes, il n'est probablement pas un utilisateur ... Mais il pourrait être difficile de bien faire les choses.

S'ils déclenchent une alerte, redirigez chaque demande vers une page statique avec le moins de DB-IO possible avec un message leur faisant savoir qu'ils seront autorisés à revenir dans X minutes.

Il est important d'ajouter que vous ne devriez probablement appliquer cela qu'aux demandes de pages et ignorer toutes les demandes de médias (js, images, etc.).

Empêcher le DoS irait à l'encontre de l'objectif n ° 2 de @ davebug qu'il a décrit ci-dessus, "Garder le site à une vitesse non ralentie par les bots", mais ne résoudrait pas nécessairement la solution n ° 1, "Vendre l'objet à des humains sans script"

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

D'accord, donc les spammeurs sont en compétition avec des gens ordinaires pour remporter l'enchère "marais"? Pourquoi ne pas faire de la prochaine vente aux enchères un "sac de merde"? Les spammeurs doivent payer beaucoup d'argent pour un sac plein de levrette, et nous en rions tous.

L'important ici est de changer le système pour supprimer la charge de votre serveur, empêcher les bots de gagner le sac de merde SANS faire savoir aux botlords que vous les jouez ou ils réviseront leur stratégie. Je ne pense pas qu'il y ait moyen de le faire sans un traitement de votre part.

Vous enregistrez donc des hits sur votre page d'accueil. Chaque fois que quelqu'un accède à la page, cette connexion est comparée à son dernier accès, et si elle était trop rapide, une version de la page est envoyée sans l'offre. Cela peut être fait par une sorte de mécanisme d'équilibrage de charge qui envoie des bots (les hits trop rapides) à un serveur qui sert simplement des versions mises en cache de votre page d'accueil; de vraies personnes sont envoyées au bon serveur. Cela supprime la charge du serveur principal et fait croire aux robots qu'ils reçoivent toujours correctement les pages.

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

Comment savez-vous que des scripteurs passent des commandes?

Le nœud de votre problème est que vous ne pouvez pas séparer les scripteurs des utilisateurs légitimes et ne pouvez donc pas les bloquer, alors comment savez-vous 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.

Tournons le problème à l'envers - vous avez des robots qui achètent des choses que vous voulez que de vraies personnes achètent, que diriez-vous de faire une vraie chance que les robots achètent des choses que vous ne voulez pas que les vraies personnes achètent.

Ayez une chance aléatoire pour certains html non affichés que les robots de grattage penseront que c'est la situation réelle, mais les vraies personnes ne verront pas (et n'oubliez pas que les vraies personnes incluent les aveugles, alors pensez aussi aux lecteurs d'écran, etc.), et cela se poursuit pour acheter quelque chose d'exorbitant cher (ou ne fait pas l'achat réel, mais obtient les détails de paiement pour vous mettre sur une liste d'interdiction).

Même si les robots changent pour «alerter l'utilisateur» plutôt que «faire l'achat», si vous pouvez obtenir suffisamment de fausses alarmes, vous pourrez peut-être le rendre suffisamment sans valeur pour les gens (peut-être pas tout le monde, mais une certaine réduction de l'arnaque est mieux que rien du tout) ne vous embêtez pas.