您可以尝试让脚本更难阅读价格。最简单的方法是将其转换为图像，但文本识别算法仍然可以解决这个问题。如果有足够多的脚本编写人员能够解决这个问题，您可以尝试对该图像应用类似验证码的东西，但显然是以牺牲用户体验为代价的。而不是图像，价格可以在一个flash应用程序。

或者，您可以尝试设计一种方法，以某种不影响呈现的方式在页面中“洗牌”HTML。我一时想不出一个好的例子，但我确信它在某种程度上是可行的。

如何像SO那样实现captcha呢?

如果你正常使用这个网站，你可能永远不会看到它。如果你经常重载同一个页面，过快地连续发布评论，或者其他触发警报的事情，让他们证明他们是人。在您的情况下，这可能是不断地重新加载同一页面，快速地跟踪页面上的每个链接，或者快速地填写订单。

如果他们连续x次检查失败(比如2次或3次)，给该IP一个超时或其他类似的措施。然后在超时结束时，再次将它们转储回检查。

---

因为你有未注册的用户访问网站，所以你只有ip地址可以继续。如果愿意，您可以向每个浏览器发出会话并以这种方式跟踪。当然，如果连续(重新)创建了太多会话，还要进行人工检查(以防机器人不断删除cookie)。

至于发现太多无辜的人，你可以在人工检查页面上发布免责声明:“如果有太多匿名用户从同一位置查看我们的网站，也可能出现此页面。我们鼓励你注册或登录以避免这种情况。”(适当调整措辞。)

此外，X个人同时从一个IP加载同一页面的几率是多少?如果它们很高，也许你需要一个不同的触发机制来触发你的机器人警报。

---

编辑:另一种选择是，如果他们失败了太多次，而你对产品的需求有信心，阻止他们，让他们亲自打电话给你来消除阻碍。

让人们打电话似乎是一种愚蠢的措施，但它可以确保计算机后面有一个人。关键是要让块只在一个几乎不应该发生的情况下出现，除非它是一个机器人(例如，连续多次检查失败)。然后它强迫人类互动——拿起电话。

对于让他们打电话给我的评论，这里显然有一个权衡。你是否担心你的用户会在打折时接几个电话?如果我如此关心产品是否能被人类用户使用，我就必须做出这个决定，可能会在这个过程中牺牲(一小部分)我的时间。

既然你似乎决心不让机器人占据上风/抨击你的网站，我相信手机可能是一个不错的选择。因为我没有从你们的产品中获利，所以我没有兴趣接这些电话。然而，如果你分享一些利润，我可能会感兴趣。因为这是你的产品，你必须决定你有多关心和相应的实现。

---

其他释放阻塞的方式都不那么有效:超时(但他们会再次关闭你的网站，冲洗-重复)，长时间超时(如果真的有人试图购买你的产品，他们会被SOL并因检查失败而受到惩罚)，电子邮件(很容易由机器人完成)，传真(相同)，或蜗牛邮件(花费太长时间)。

当然，您也可以在每个IP每次超时时增加超时时间。只要确保你不是在不经意间惩罚真正的人类。

我说使用API公开价格信息。这是一个不太直观的解决方案，但它确实能让你控制局面。为API添加一些限制，使其功能略低于网站。

您可以对订购进行同样的操作。您可以尝试对API功能/性能进行小的更改，直到获得所需的效果。

有代理和僵尸网络来挫败IP检查。有一些验证码读取脚本非常好。在印度，甚至有一些团队的工作人员可以花很少的钱来破解验证码。任何你能想到的解决方案都有可能被击败。即使是Ned Batchelder的解决方案也可以通过使用WebBrowser控件或其他与僵尸网络或代理列表相结合的模拟浏览器来超越。

看看ned Batchelder的这篇文章。他的文章是关于阻止垃圾邮件机器人的，但是同样的技术可以很容易地应用到您的站点。

而不是阻止机器人 人们可以识别自己，我们可以 通过增加难度来阻止机器人 为了让他们的帖子成功，或者 通过让他们无意中识别 他们自己就是机器人。这将删除 负担从人而来，而离去 评论形式免费可见的反垃圾邮件 措施。 这个技巧就是我预防的方法 这个网站上的垃圾邮件。它的工作原理。的 这里描述的方法不查看 根本就是内容。

其他一些想法:

创建一个官方的自动通知机制(RSS feed?Twitter?)当你的产品上市时，人们可以订阅它。这减少了人们编写脚本的需求。 在新商品上市前改变你的迷惑技巧。因此，即使编剧可以升级军备竞赛，他们也总是落后一天。

---

编辑:为了完全清楚，Ned在上面的文章中描述了通过防止BOT通过表单提交订单来防止自动购买物品的方法。他的技术并不能阻止机器人通过抓取主页来判断什么时候有Bandoleer of carrot出售。我不确定防止这种情况是否真的可能。

关于你对内德策略有效性的评论:是的，他讨论了蜜罐，但我不认为那是他最强的策略。他对SPINNER的讨论是我提到他的文章的最初原因。对不起，我在最初的帖子中没有说清楚:

转轮是一个隐藏字段，用于 一些东西:它将A哈希在一起 防止的值的数目 篡改和重播，并已习惯 模糊的字段名。旋转器是 MD5哈希值: 时间戳, 客户端的IP地址， 被评论的博客条目的条目id，以及 一个秘密。

以下是你如何在WOOT.com上实现它:

每次有新商品出售时，更改作为散列一部分的“secret”值。这意味着，如果有人打算设计一个BOT来自动购买物品，它只会在下一个物品开始销售之前起作用!!

即使有人能够快速重建他们的机器人，所有其他实际用户都已经购买了BOC，你的问题就解决了!

他讨论的另一个策略是不时地改变蜜罐技巧(同样，当新产品上市时改变它):

Use CSS classes (randomized of course) to set the fields or a containing element to display:none. Color the fields the same (or very similar to) the background of the page. Use positioning to move a field off of the visible area of the page. Make an element too small to show the contained honeypot field. Leave the fields visible, but use positioning to cover them with an obscuring element. Use Javascript to effect any of these changes, requiring a bot to have a full Javascript engine. Leave the honeypots displayed like the other fields, but tell people not to enter anything into them.

我想我的总体想法是在每个新产品上市时改变形式设计。或者至少，当一款新的中行上市时，它会有所改变。

一个月几次吗?

免责声明:这个答案完全与编程无关。但是，它确实试图从一开始就攻击使用脚本的原因。

另一个想法是，如果你的销售数量确实有限，为什么不改变先到先得的方法呢?当然，除非炒作是你营销计划的一部分。

还有很多其他的选择，我相信其他人也能想到一些不同的选择:

an ordering queue (pre-order system) - Some scripts might still end up at the front of the queue, but it's probably faster to just manually enter the info. a raffle system (everyone who tries to order one is entered into the system) - This way the people with the scripts have just the same chances as those without. a rush priority queue - If there is truly a high perceived value, people may be willing to pay more. Implement an ordering queue, but allow people to pay more to be placed higher in the queue. auction (credit goes to David Schmitt for this one, comments are my own) - People can still use scripts to snipe in at the last minute, but not only does it change the pricing structure, people are expecting to be fighting it out with others. You can also do things to restrict the number of bids in a given time period, make people phone in ahead of time for an authorization code, etc.

对每分钟发出如此多请求的用户代理进行计时。例如，如果有人在10分钟内每5秒请求一个页面，他们可能不是用户。但要做到这一点可能很棘手。

如果他们触发警报，将每个请求重定向到一个静态页面，尽可能少地使用DB-IO，并发送消息让他们知道他们将在X分钟内被允许返回。

重要的是，你应该只在页面请求上应用这个，忽略所有的媒体请求(js，图像等)。

引入一种需要人类互动的延迟，就像一种“验证码游戏”。例如，这可能是一款Flash小游戏，玩家必须在30秒内爆开格子球，并避免爆开实心球(避免色盲问题!)游戏将获得一个随机数种子，游戏将向服务器传输点击点的坐标和时间戳，以及使用的种子。

在服务器上，你可以使用种子来模拟游戏机制，看看点击是否真的会击破球。如果他们这样做了，他们不仅是人类，而且还会花30秒来验证自己。给他们一个会话id。

你让会话id做它喜欢做的事情，但是如果发出太多请求，它们就不能继续，除非再次播放。

已经发布了一些其他/更好的解决方案，但为了完整起见，我想我会提到这个:

If your main concern is performance degradation, and you're looking at true hammering, then you're actually dealing with a DoS attack, and you should probably try to handle it accordingly. One common approach is to simply drop packets from an IP in the firewall after a number of connections per second/minute/etc. For example, the standard Linux firewall, iptables, has a standard operation matching function 'hashlimit', which could be used to correlate connection requests per time unit to an IP-address.

虽然，这个问题可能更适合于上一个so播客中提到的下一个so衍生产品，它还没有推出，所以我想可以回答:)

编辑: 正如novatrust指出的那样，仍然有ISP实际上没有分配ip给他们的客户，因此有效地，这样一个ISP的脚本客户将禁用该ISP的所有客户。

Provide an RSS feed so they don't eat up your bandwidth. When buying, make everyone wait a random amount of time of up to 45 seconds or something, depending on what you're looking for exactly. Exactly what are your timing constraints? Give everyone 1 minute to put their name in for the drawing and then randomly select people. I think this is the fairest way. Monitor the accounts (include some times in the session and store it?) and add delays to accounts that seem like they're below the human speed threshold. That will at least make the bots be programmed to slow down and compete with humans.

I'm not seeing the great burden that you claim from checking incoming IPs. On the contrary, I've done a project for one of my clients which analyzes the HTTP access logs every five minutes (it could have been real-time, but he didn't want that for some reason that I never fully understood) and creates firewall rules to block connections from any IP addresses that generate an excessive number of requests unless the address can be confirmed as belonging to a legitimate search engine (google, yahoo, etc.).

此客户端运行一个web托管服务，并在三台服务器上运行此应用程序，这三台服务器总共处理800-900个域。峰值活动在每秒1000次的范围内，从来没有性能问题-防火墙在从黑名单地址丢弃数据包时非常有效。

是的，DDOS技术确实存在，可以击败这个计划，但他没有看到这种情况在现实世界中发生。相反，他说这大大降低了他服务器的负载。

防止DoS会挫败@davebug上面所概述的第二个目标，“保持网站的速度不被机器人减慢”，但不一定能解决第一个目标，“把项目卖给非脚本编制的人”。

我敢肯定，脚本编写人员可以编写一些东西来在过度的限制下滑行，这仍然比人类完成排序表单的速度要快。

问:你如何阻止脚本写手在一秒钟内上百次地攻击你的网站? A:你不需要。外部代理无法阻止这种行为。

你可以使用大量的技术来分析传入的请求，并尝试启发式地确定谁是人，谁不是人……但它会失败。最终，即使不是马上。

唯一可行的长期解决方案是改变游戏，使网站不再对机器人友好，或者减少对编剧的吸引力。

你是怎么做到的?那是另一个问题了!: -)

...

好吧，上面已经给出了一些选项(并拒绝了)。我对你的网站不是很熟悉，只看过一次，但由于人们可以阅读图像中的文本，而机器人无法轻松做到这一点，所以将公告更改为图像。不是验证码，只是一个图像-

generate the image (cached of course) when the page is requested keep the image source name the same, so that doesn't give the game away most of the time the image will have ordinary text in it, and be aligned to appear to be part of the inline HTML page when the game is 'on', the image changes to the announcement text the announcement text reveals a url and/or code that must be manually entered to acquire the prize. CAPTCHA the code if you like, but that's probably not necessary. for additional security, the code can be a one-time token generated specifically for the request/IP/agent, so that repeated requests generate different codes. Or you can pre-generate a bunch of random codes (a one-time pad) if on-demand generation is too taxing.

运行真实的人对这个问题的响应的时间试验，并忽略('哎呀，发生错误，对不起!请再试一次’)的反应比一半的时间要快。此事件还应该触发警报，提醒开发者至少有一个机器人已经弄清楚了代码/游戏，所以是时候修改代码/游戏了。

继续定期地改变游戏，即使没有机器人触发它，这只是在浪费编剧的时间。最终，编剧会厌倦这款游戏，去别的地方……我们希望;-)

最后一个建议:当你的主页收到请求时，把它放到一个队列中，然后在一个单独的进程中按顺序响应请求(你可能不得不入侵/扩展web服务器来做到这一点，但这可能是值得的)。如果来自同一IP/代理的另一个请求进入，而第一个请求在队列中，忽略它。这将自动减轻机器人的负载。

编辑:另一种选择，除了使用图像，是使用javascript来填写购买/不购买的文本;机器人很少解释javascript，所以他们不会看到它

与其阻止可疑的ip，不如随着点击率/分钟的上升而减少你提供给一个地址的数据量。因此，如果机器人击中你超过一个秘密随机变化的阈值，它将不会看到数据。登录的用户总是能看到这些数据。经常访问服务器的登录用户将被迫重新验证身份，或者被给予验证码。

我不知道这是否可行:……主动出击。

搞清楚机器人在扫描什么数据。给他们提供他们正在寻找的数据，当你不卖垃圾时。以一种不会打扰或迷惑人类用户的方式进行此操作。当机器人触发第二阶段时，他们将登录并填写表格，购买100美元的roomba，而不是BOC。当然，这是假设机器人不是特别健壮。

另一个想法是在促销期间随机降价。当你明确声明它只值20美元时，谁会花150美元买一袋垃圾?没有人，只有狂热的机器人。但9分钟后就变成了35美元…17分钟后是9美元。之类的。

当然，僵尸国王能够做出反应。关键是要让他们的错误变得非常昂贵(并让他们付钱给你来与他们战斗)。

所有这些都假设你想要惹恼一些机器人领主，这可能不是100%可取的。

好吧，所以垃圾邮件发送者在和普通人竞争赢得“垃圾沼泽”拍卖?为什么不让下一次拍卖变成一堆垃圾呢?垃圾邮件发送者可以花大钱买一袋狗屎，我们都嘲笑他们。

这个问题的解决方案可能是在登录和购买操作中附加一些客户端处理。处理量可以忽略不计，因此个人不会受到影响，但多次尝试执行任务的机器人将受到额外工作负载的阻碍。

处理过程可以是一个用javascript解决的简单方程，除非你不想在你的网站上需要javascript。

嗯，我记得读过“Linux防火墙”攻击检测和响应… 那里的情况似乎非常相似。有人也这么说过。只是暂时阻止客户或逐步限制他们。如果它是真的yl从几个网站，这必须是相当有效的

问候

你需要想办法让机器人购买价格过高的东西:12毫米的坚果:20美元。看看有多少机器人在编剧认为你在耍他们之前抢了过来。

用这些利润购买更多的服务器和支付带宽。

Woot用来解决这个问题的方法正在改变游戏。当他们展示一种非常受欢迎的商品出售时，他们会让用户玩电子游戏来订购它。

这不仅能够有效地对抗机器人(它们能够轻松地对游戏进行一些小改变以避免自动玩家，甚至为每次销售提供一个新游戏)，而且还能够给用户一种“赢得”所需道具的印象，同时减缓订购过程。

它仍然很快就卖光了，但我认为解决方案是好的——重新评估问题和改变参数导致了一个成功的战略，而严格的技术解决方案根本不存在。

---

你的整个商业模式都是基于“先到先得”。你不能像广播电台那样(他们不再把第一个打电话的人视为赢家，而是把第5个、第20个或第13个打电话的人视为赢家)——这与你的主要特点不匹配。

不，如果不改变实际用户的订购体验，就无法做到这一点。

假设你实施了所有这些策略。如果我认为这很重要，我就会找100个人和我一起工作，我们会在100台不同的电脑上构建软件，每秒访问你的网站20次(每个用户/cookie/帐户/IP地址访问间隔5秒)。

你有两个阶段:

看头版 订购

你不能设置一个验证码阻塞#1 -那样会失去真正的客户(“什么?每次我想看最新的woot时，我都必须解决验证码?!?”)。

所以我的小组一起观察，计时，所以我们每秒得到大约20次检查，第一个看到变化的人会提醒所有其他人(自动)，他们将再次加载首页，遵循订单链接，并执行交易(这也可能是自动发生的，除非你实现验证码并为每次wootoff/boc更改它)。

你可以把验证码放在第2条前面，虽然你不愿意这么做，但这可能是确保即使机器人看首页，真正的用户也能得到产品的唯一方法。

但即使有验证码，我的100个小团队仍然有显著的先发优势——而且你无法分辨我们不是人类。如果你开始计时我们的访问，我们只会增加一些抖动。我们可以随机选择要刷新的计算机，这样访问顺序就会不断变化，但看起来仍然足够像人类。

首先，摆脱简单的机器人

你需要有一个自适应防火墙来监视请求，如果有人在做明显的愚蠢的事情——在同一个IP上每秒刷新一次以上，那么就采用策略来减慢他们的速度(丢弃数据包，发回拒绝或500个错误，等等)。

这将显著降低你的流量，并改变机器人用户使用的策略。

第二，让服务器非常快。

你真的不想听这个…但是…

我认为你需要的是一个完全自定义的解决方案。

您不需要打乱TCP/IP堆栈，但是您可能需要开发一个非常、非常、非常快的定制服务器，该服务器是专门用于关联用户连接并对各种攻击做出适当反应的。

Apache, lighthttpd等都很灵活，但你运行的是一个单一用途的网站，你真的需要能够做的比当前服务器所能做的更多(无论是在处理流量，还是在适当地打击机器人)。

By serving a largely static webpage (updates every 30 seconds or so) on a custom server you should not only be able to handle 10x the number of requests and traffic (because the server isn't doing anything other than getting the request, and reading the page from memory into the TCP/IP buffer) but it will also give you access to metrics that might help you slow down bots. For instance, by correlating IP addresses you can simply block more than one connection per second per IP. Humans can't go faster than that, and even people using the same NATed IP address will only infrequently be blocked. You'd want to do a slow block - leave the connection alone for a full second before officially terminating the session. This can feed into a firewall to give longer term blocks to especially egregious offenders.

但现实是，无论你做什么，当机器人是由人类为单一目的定制时，都无法将人类与机器人区分开来。机器人只是人类的代理。

结论

在一天结束的时候，你不能通过看头版来区分人类和计算机。您可以在订购步骤停止机器人，但机器人用户仍然具有先发优势，并且您仍然需要管理巨大的负载。

你可以为简单的机器人添加块，这将提高标准，更少的人会为它烦恼。这也许就足够了。

但如果不改变你的基本模型，你就不走运了。你能做的最好的事情就是处理好简单的情况，让服务器快速到普通用户注意不到的程度，并出售大量道具，即使你有数百万个机器人，许多想要它们的普通用户也会得到它们。

你可能会考虑建立一个蜜罐，并将用户帐户标记为机器人用户，但这将引起巨大的负面社区反弹。

每次我想到“好吧，这样做怎么样?”我总是可以用合适的机器人策略来对抗它。

即使你在首页设置了一个验证码来进入订购页面(“这个项目的订购按钮是蓝色的，带粉红色的火花，在这个页面的某个地方”)，机器人也会简单地打开页面上的所有链接，并使用返回订购页面的任何一个链接。这根本不可能赢。

提高服务器的速度，在订购页面上输入reCaptcha(这是我发现的唯一一个不容易被愚弄的方法，但对你的应用程序来说可能太慢了)，并考虑如何稍微改变模型，让普通用户有和机器人用户一样好的机会。

亚当

我的解决方案是，通过为“机器人和脚本”设置大约10分钟的延迟，让屏幕抓取变得毫无价值。

以下是我的做法:

记录并识别任何重复作案的人。

你不需要记录每次点击的每个IP地址。大概每20次点击只录一次。一个惯犯仍然会在随机的偶尔跟踪中出现。

保留大约10分钟前页面的缓存。 当重复攻击者/机器人攻击您的网站时，给他们10分钟前的缓存页面。

他们不会马上意识到他们得到的是一个旧网站。他们可以把它刮掉，但他们不会再赢得任何比赛了，因为“真人”会有10分钟的领先优势。

好处:

没有麻烦或问题的用户(如验证码)。 完全在服务器端实现。(不依赖Javascript/Flash) 提供一个较旧的缓存页面的性能强度应该小于活动页面。这样实际上可以减少服务器的负载!

缺点

需要跟踪一些IP地址 需要保持和维护旧页面的缓存。

我们目前正在使用F5的最新一代BigIP负载均衡器来实现这一点。BigIP具有先进的流量管理功能，可以根据频率和使用模式识别抓取者和机器人，甚至可以从单个IP后面的一组源中识别。然后，它可以限制这些内容，为它们提供替代内容，或者简单地用标题或cookie标记它们，以便您可以在应用程序代码中识别它们。

My approach would be to focus on non-technological solutions (otherwise you're entering an arms race you'll lose, or at least spend a great deal of time and money on). I'd focus on the billing/shipment parts - you can find bots by either finding multiple deliveries to same address or by multiple charges to a single payment method. You can even do this across items over several weeks, so if a user got a previous item (by responding really really fast) he may be assigned some sort of "handicap" this time around.

这也会有一个副作用(我认为是有益的，但从营销角度来看，我可能是错误的)，可能会扩大幸运的人的圈子，购买woot。

首先，根据定义，它不可能支持无状态，即真正匿名的事务，同时还能够将机器人与合法用户分开。

如果我们可以接受这样一个前提，即我们可以在一个全新的woot访问者的第一页点击上强加一些成本，我想我有一个可能的解决方案。由于没有更好的名称，我将粗略地称这种解决方案为“访问DMV”。

假设有一家汽车经销商每天提供一辆不同的新车，在某些日子里，你可以以每辆5美元的价格购买一辆异国情调的跑车(最多3辆)，外加5美元的目的地费。

问题是，经销商要求你去经销商处并出示有效的驾驶执照，然后你才能被允许通过门查看正在出售的汽车。此外，你必须说有效的驾驶执照才能购买。

因此，第一次来这家汽车经销商的游客(让我们叫他鲍勃)会被拒绝进入，并被推荐到DMV办公室(就在隔壁，很方便)获得驾驶执照。

其他持有效驾驶执照的旅客出示驾驶执照后，方可进入。一个整天在店里闲逛、纠缠推销员、抢宣传册、喝光免费赠送的咖啡和饼干的人最终会被拒之门外。

现在，回到没有驾照的鲍勃，他所要做的就是忍受一次车管所的访问。在那之后，他可以随时去经销商那里买车，除非他不小心把钱包落在家里了，或者他的驾照被销毁或吊销了。

在这个世界上，驾照几乎是不可能伪造的。

去车管所首先要在“从这里开始”的队列处领取申请表。Bob必须把填好的申请拿到窗口1，在那里，许多脾气暴躁的公务员中的第一个会拿着他的申请，处理它，如果一切正常，就在窗口的申请上盖章，然后把他送到下一个窗口。于是，鲍勃从一个窗口走到另一个窗口，等待他的申请的每一步通过，直到最后他拿到了他的驾驶执照。

试图“短路”车管所是没有意义的。如果表单一式三份没有正确填写，或者在任何窗口中给出错误的答案，应用程序将被销毁，倒霉的客户将被送回起点。

有趣的是，无论办公室是满是空，每个窗口的服务时间都差不多。即使你是唯一一个排队的人，工作人员似乎也喜欢让你在黄线后面等一分钟，然后才说:“下一个!”

然而，车管所的情况并没有那么糟糕。当所有的等待和获得许可证的过程正在进行时，你可以在DMV大厅观看一个非常有趣和有信息的汽车经销商的电视购物。事实上，该信息购物的运行时间仅够覆盖您获得许可证所花费的时间。

更专业一点的解释是:

正如我在最上面所说的，在客户机-服务器关系上有一定的状态性是必要的，它允许您将人类与机器人分开。您希望以一种不会过度惩罚匿名(未经过身份验证)人类访问者的方式进行操作。

这种方法可能需要AJAX-y客户端处理。一个全新的woot访问者会看到一个“欢迎新用户!”页面，其中充满了文本和图形(通过适当的服务器端调整)，需要几秒钟才能完全加载。在此过程中(访问者可能正忙着阅读欢迎页面)，他的标识令牌正在慢慢地组装起来。

Let's say, for discussion, the token (aka "driver's license) consists of 20 chunks. In order to get each successive chunk, the client-side code must submit a valid request to the server. The server incorporates a deliberate delay (let's say 200 millisecond), before sending the next chunk along with the 'stamp' needed to make the next chunk request (i.e., the stamps needed to go from one DMV window to the next). All told, about 4 seconds must elapse to finish the chunk-challenge-response-chunk-challenge-response-...-chunk-challenge-response-completion process.

在这个过程的最后，访问者拥有一个令牌，该令牌允许他进入产品描述页面，然后进入购买页面。令牌是每个访问者的唯一ID，可以用来限制他的活动。

在服务器端，您只接受来自具有有效令牌的客户机的页面视图。或者，如果每个人最终都能看到页面很重要，那么对缺少有效令牌的请求设置时间惩罚。

现在，为了使这对合法的人类访问者来说相对无害，我们不要让令牌发行过程在后台相对非侵入性地发生。因此，欢迎页面需要带有有趣的文字和故意放慢速度的图形。

这种方法迫使机器人要么使用现有的令牌，要么使用最少的设置时间来获得新的令牌。当然，这对使用分布式假访问者网络的复杂攻击没有太大帮助。

不管纳粹认为他们的通信有多安全，盟军经常会破坏他们的信息。无论你如何试图阻止机器人使用你的网站，机器人所有者都会想出一个方法来解决它。如果这让你成为纳粹，我很抱歉:-)

我认为需要一种不同的心态

不要试图阻止机器人使用你的网站 不去寻求立即见效的解决办法，打持久战

要有这样一种心态:不管你网站的客户是真人还是机器人，他们都只是付费客户;但其中一个比另一个有不公平的优势。一些没有太多社交生活的用户(隐士)可能会像机器人一样让你的网站的其他用户讨厌。

记录您发布报价的时间和帐户选择购买的时间。

这可以让你记录下速度 客户在买东西。

改变你发布优惠的时间。

例如，设置3小时的窗口 从某个不知名的时间开始 天(午夜?)只有机器人和隐士 会不断刷新一个页面3 好几个小时才拿到订单 秒。不要改变基准时间， 只有窗户的大小。

随着时间的推移，一幅图景就会浮现出来。

01:你可以看到哪些账户经常在产品上线后几秒钟内购买产品。这表明他们可能是机器人。

02:你也可以看看促销的时间窗口，如果窗口是1小时，那么一些早期买家将是人类。然而，人类很少会在4小时内恢复精神。如果发布/购买之间的运行时间相当一致，而不考虑窗口持续时间，那么这就是一个bot。如果发布/购买时间对于小窗口很短，而对于大窗口很长，那就是隐士!

现在不是阻止机器人使用你的网站，你有足够的信息告诉你哪些账户肯定被机器人使用，哪些账户可能被隐士使用。你如何处理这些信息取决于你，但你当然可以用它来让你的网站对有生活的人更公平。

我认为禁止机器人账户是毫无意义的，这就像打电话给希特勒说“谢谢你的u艇的位置!”你需要以一种账户所有者不会意识到的方式使用这些信息。让我们看看我是否能想出什么.....

在队列中处理订单:

当客户下订单时，他们会立即收到一封确认电子邮件，告诉他们他们的订单已被放入队列中，并将在处理完毕时收到通知。我在亚马逊上的订单/发货就经历过这种事情，这一点也不困扰我，我不介意几天后收到一封电子邮件，告诉我我的订单已经发货了，只要我立即收到一封电子邮件，告诉我亚马逊知道我想要这本书。在你的情况下，这将是一封电子邮件

您的订单已经下单，正在排队。 您的订单已经处理完毕。 您的订单已发出。

用户认为他们排在一个公平的队列中。每1小时处理一次队列，让普通用户也经历一次队列，以免引起怀疑。只有在机器人和隐士账户排队超过“人类平均下单时间+ x小时”后，才会处理他们的订单。有效地减少机器人对人类的影响。

这里最重要的事情是改变系统，从你的服务器上移除负载，防止机器人在不让奶瓶商知道你在和他们玩游戏的情况下赢得这袋垃圾，否则他们会修改他们的策略。我认为如果你们不进行一些处理，就没有办法做到这一点。

So you record hits on your home page. Whenever someone hits the page that connection is compared to its last hit, and if it was too quick then it is sent a version of the page without the offer. This can be done by some sort of load balancing mechanism that sends bots (the hits that are too fast) to a server that simply serves cached versions of your home page; real people get sent to the good server. This takes the load off the main server and makes the bots think that they are still being served the pages correctly.

如果这个提议能以某种方式被拒绝就更好了。然后你仍然可以在假服务器上提供报价，但当机器人填写表格时，说“对不起，你不够快”:)然后他们肯定会认为他们还在游戏中。

使用JavaScript动态地将信息写入页面。如果没有JS渲染引擎，屏幕抓取器和机器人肯定无法读取信息。

我将要描述的方法有两个要求。1) Javascript被强制执行2)一个具有有效http://msdn.microsoft.com/en-us/library/bb894287.aspx浏览器会话的web浏览器。

如果没有其中任何一个，你就是“故意”倒霉的。互联网被设计成允许匿名客户查看内容。简单的HTML没有办法解决这个问题。哦，我只是想说，简单的，基于图像的验证码很容易被击败，甚至作者也承认这一点。

Moving along to the problem and the solution. The problem is in two parts. The first is that you cannot block out an individual for "doing bad things". To fix this you setup a method that takes in the browsers valid session and generate a md5sum + salt + hash (of your own private device) and send it back to the browser. The browser then is REQUIRED to return that hashed key back during every post / get. If you do not ever get a valid browser session, then you reply back with "Please use a valid web browser blah blah blah". All popular browsers have valid browser session id's.

现在我们至少有了该浏览器会话的标识(我知道它不会永久锁定，但是通过简单的脚本很难“更新”一个浏览器会话)，我们可以有效地锁定一个会话(例如;让脚本编写人员很难访问你的网站，而不会对有效用户造成任何惩罚)。

Now this next part is why it requires javascript. On the client you build a simple hash for each character that comes from the keyboard versus the value of the text in the textarea. That valid key comes over to the server as a simple hash and has to be validated. While this method could easily be reverse engineered, it does make it one extra hoop that individuals have to go through before they can submit data. Mind you this only prevents auto posting of data, not DOS with constant visits to the web site. If you even have access to ajax there is a way to send a salt and hash key across the wire and use javascript with it to build the onkeypress characters "valid token" that gets sent across the wire. Yes like I said it could easily be reversed engineered, but you see where I am going with this hopefully.

现在为了防止不断的交通滥用。有几种方法可以在给定有效的会话id后建立模式。这些模式(即使使用Random来抵消请求时间)的epsilon比人类试图重现相同的误差范围时要低。由于您有一个会话ID，并且您有一个“看起来像一个bot”的模式，那么您可以用一个简单的轻量级响应屏蔽该会话，该响应是20字节而不是200000字节。

You see here, the goal is to 1) make the anonymous non-anonymous (even if it's only per session) and 2) develop a method to identify bots vs. normal people by establishing patterns in the way they use your system. You can't say that the latter is impossible, because I have done it before. While, my implementations were for tracking video game bots I would seem to think that those algorithms for identifying a bot vs. a user can be generalized to the form of web site visits. If you reduce the traffic that the bots consume you reduce the load on your system. Mind you this still does not prevent DOS attacks, but it does reduce the amount of strain a bot produces on the system.

将道具卖给非脚本人。 保持网站运行的速度不被机器人减慢。 不要让“正常”用户完成任何任务来证明他们是人类。

你可能不想听这个，但是第一条和第三条是相互排斥的。

Well, nobody knows you're a bot either. There's no programatic way to tell the whether or not there's a human on the other end of the connection without requiring the person to do something. Preventing scripts/bots from doing stuff on the web is the whole reason CAPTCHAs were invented. It's not like this is some new problem that hasn't seen a lot of effort expended on it. If there were a better way to do it, one that didn't involve the hassle to real users that a CAPTCHA does, everyone would be using it already.

我认为你需要面对这样一个事实，如果你想让机器人远离你的订购页面，一个好的验证码是唯一的方法。如果对你的随机垃圾的需求足够高，人们愿意付出这些代价来获得它，合法用户就不会被验证码吓跑。

I think that sandboxing certain IPs is worth looking into. Once an IP has gone over a threshold, when they hit your site, redirect them to a webserver that has a multi-second delay before serving out a file. I've written Linux servers that can handle open 50K connections with hardly any CPU, so it wouldn't be too hard to slow down a very large number of bots. All the server would need to do is hold the connection open for N seconds before acting as a proxy to your regular site. This would still let regular users use the site even if they were really aggressive, just at a slightly degraded experience.

您可以使用这里描述的memcached，以较低的成本跟踪每个IP的命中数。

To solve the first problem of the bots slamming your front page, try making the honeypot exactly the same as a real bag of crap. Make the html markup for the front page include the same markup as if it were for a bag of crap, but make it hidden. This would force the bots to include CSS engines to determine if the bag of crap code is displayed or hidden. Alternatively, you could only output this 'fake' bag of crap html a random amount of time (hours?) before a real bag of crap goes up. This would cause the bots to sound the alarm too soon (but not know how soon).

第二步是真正购买一袋垃圾，添加一些简单的问题。比起上面提到的数学问题，我更喜欢常识问题。比如，“冰是热的还是冷的?”“蚂蚁是大还是小?”当然，这些问题需要随机抽取，从无穷无尽的问题中抽取，否则机器人可以通过编程来回答这些问题。不过，这些问题仍然远没有验证码那么烦人。

那么使用Flash呢?

是的，我知道使用Flash的开销，加上一些用户将无法购买这些垃圾(即iPhone用户)，这可能会造成不利影响，但在我看来，Flash可以防止屏幕抓取或至少使其变得困难。

我错了吗?

编辑添加

在你的提交表单上添加几个“隐藏”字段怎么样，就像我下面发现的那样:

Actually, best practice seems to be to use two hidden fields, one with an initial value, and one without. It's the rare bot which can ignore both fields. Check for one field to be blank, and the other to have the initial value. And hide them using CSS, not by making them "hidden" fields: .important { display : none ; } Please don't change the next two fields. Bots tend to like fields with names like 'address'. The text in the paragraph is for those few rare human beings who have a non-CSS capable browser. If you're not worried about them, you can leave it out. In the logic for processing the form, you'd do something like: if (address2 == "xyzzy" and address3 == "") { /* OK to send / } else { / probably have a bot */ }

Go after the money stream. It is much easier than tracking the IP side. Make bots pay too much a few times (announcement with white text on white background and all variants of it) kills their business case quickly. You should prepare this carefully, and make good use of the strong points of bots: their speed. Did you try a few thousand fake announcements a few seconds apart? If they are hitting ten times/second you can go even faster. You want to keep this up as long as they keep buying, so think carefully about the moment of the day/week you want to start this. Ideally, they will stop paying, so you can hand over your case to a bank. Make sure your site is fully generated, and each page access returns different page content (html, javascript and css). Parsing is more difficult than generating, and it is easy to build-in more variation than bot developers can handle. Keep on changing the content and how you generate it. You need to know how fast bots can adapt to changes you make, and preferably the timezone they are in. Is it one botnet or more, are they in the same timezone, a different one, or is it a worldwide developer network? You want your counterattack to be timed right. Current state of the art bots have humans enter captcha's (offered against porn/games). Make it unattractive to react very fast. Use hashes and honeypots, as Ned Batchelder explains.

(编辑) 你不能防御僵尸网络的说法是不对的。特别是我的第二个建议提供了充分的防御自动买家。不过，这需要你彻底重新思考你所使用的技术。您可能希望使用Seaside或直接在c中进行一些实验。

你不能完全阻止机器人，即使有验证码。但是，您可以让编写和维护机器人变得痛苦，从而减少机器人的数量。特别是强迫他们每天更新他们的机器人，你会让大多数人失去兴趣。

下面是一些让机器人更难编写的想法:

Require running a javascript function. Javascript makes it much more of a pain to write a bot. Maybe require a captcha if they aren't running javascript to still allow actual non-javascript users (minimal). Time the keystrokes when typing into the form (again via javascript). If it's not human-like then reject it. It's a pain to mimic human typing in a bot. Write your code to update your field ID's daily with a new random value. This will force them to update their bot daily which is a pain. Write your code to re-order your fields on a daily basis (obviously in some way that's not random to your users). If they're relying on the field order, this will trip them up and again force daily maintenance to their bot code. You could go even further and use Flash content. Flash is totally a pain to write a bot against.

一般来说，如果你开始采取一种不阻止他们的心态，而是让他们更加努力，你可能会实现你正在寻找的目标。

大多数纯技术解决方案已经提供。因此，我将提出这个问题的另一种看法。

据我所知，这些机器人是由真正想买你卖的包的人设置的。问题是——

其他不操作机器人的人应该有购买的机会，而你提供的是有限数量的包。 你想要吸引人们到你的网站，而只是销售包包。

你可以让潜在的包包买家订阅电子邮件，甚至短信更新，以便在交易发生时收到通知，而不是试图避开机器人。你甚至可以给他们一到两分钟的时间(一个销售开始的特殊URL，随机生成，并随邮件/短信发送)。

当这些买家去购买他们在你的网站上，你可以向他们展示你想要的任何东西。那些运行机器人将更喜欢简单地注册到您的通知服务。

机器人运行者可能仍然会在你的通知中运行机器人以更快地完成购买。一些解决方案可以提供一键购买。

顺便说一下，你提到你的用户不是注册的，但听起来那些购买这些包的人不是随机的买家，而是期待这些销售的人。因此，他们可能愿意注册，以便在试图“赢得”一个包时获得优势。

从本质上讲，我的建议是试着把这个问题看作一个社会问题，而不是一个技术问题。

Asaf

假定原则:

第一个屏幕必须是非常简单的低开销HTML，带有一个易于识别的按钮(游戏邦注:无论是机器人还是玩家)，以明确表示“我想要我的垃圾”。因为我们假设了最坏的情况-你有来自机器人和非机器人组合的DOS攻击，所有人都首先点击网站(就可识别性而言)。所以让我们尽快把这些从缓存，良性回声机器人等中分发出去。

(注:就追求者而言，这就是发生的事情;这对用户和Woot来说都是痛苦的，所以任何有助于吸收或缓解首次屏幕获取的内容都符合三方的利益。)

然后，对于非机器人来说，这个过程不需要比现在更糟糕，对于正版机器人来说，不需要额外的步骤(或痛苦)。(关于当前设计的背景说明:当前的wooters通常已经签约，或者可以在购买过程中签约。新买家需要在购买时进行注册。所以实际上已经注册和已经登录会更快。)

为了完成垃圾销售，需要导航一系列交易屏幕(比如5个正负，取决于具体情况)。获胜者是第一个完成全部导航的人。当前进程奖励那些最快完成整个5个屏幕序列的机器人(或其他人);但整个进程都偏向于快速响应(即机器人)。

毫无疑问，机器人将在第一个屏幕上占据优势;无论他们在这一点上取得了什么优势，他们都会在剩下的屏幕上保持下去，再加上身体在其他阶段提供的任何优势。

---

What if Woot were to intentionally decouple the queuing process after the first screen, and feed every session from that point into a sequence of fixed-minimum-time steps? The second screen wouldn't even be presented until 30 seconds had passed; after it was submitted, same for the following screens. I bet wooters would have no problem if they were told that, after the first screen, they would wait in a queue (which is already true) that would spread the load over time in a way that should take no longer than before, be more robust, and help weed out the bots. At this point you can throw in some of the bot speedbumps listed above (subtle variations in DOM objects, etc.) Just the benefit from the perception that Woot is a little more in control of things would help.

If a much higher proportion of the BOC initial hits could segue into a bot-unfriendlier non-time-critical process on their first hit (or close to it), rather than retrying, then real people who get past that point would have more confidence. For sure it would be less hostile than the current situation. It might cut down on the background-noise-ambient-bot-rate that's going on all the time even under normal Woot-Off circumstances. And the bots would lay off the main page and sit in the queue with each other (and everyone else) where they have no advantage.

Hmmm... The concept "apartment-threaded" comes to mind. I wonder if the pattern is approximately useful? A useful core concept here is being able, after the first screen, to track accumulated total time in queue and be able to adjust to standard. As a bot-mitigation strategy, you would have a little bit of flexibility to maybe fudge the very earliest sessions by maybe 5-10 seconds; doing so would probably be undetectable, but would result in a richer non-bot purchase mix. I'm sure you have statistics to help evaluate stuff like this after the fact. Just for fun, you could (at least for one wootoff) put together your own bot that combines the best features you've seen, and then hand it out to everyone the day before. Then at least everyone would be equally armed. (Then duck ... incoming ...)

我喜欢BradC的回答(使用Ned Batchelder文章中的建议)，但我想在此基础上再增加一个层次。您不仅可以随机化字段名称，还可以随机化字段位置和使它们不可见的代码。

Now, this last bit is hard part and I don't know exactly how to do it, but someone with more JavaScript and CSS experience might be able to figure it out. Of course, you can't just keep the same positions all the time, because the scripters will just figure out that the element with position (x,y) is the real one. You would have to have some code that changes the positioning of form elements relative to other elements in order to move them off the page, overlay them on each other, etc. Then obfuscate the code that does this with some randomness introduced into it. Automatically change the obfuscation daily, before a new item is made available. The idea is that without a proper CSS and JavaScript implementation (and code to read layout of the page as a human would) a bot won't be able to figure out which elements are being shown to the user. Your server-side code, of course, knows which fields are real and which are fake.

总而言之:

字段名是随机的 字段顺序是随机的 字段隐藏代码很复杂 字段隐藏代码是随机混淆的 服务器端代码每天自动更改随机因子

在你给出的限制条件下，我不认为有办法避免某种形式的“军备竞赛”，但这并不意味着一切都完了。如果你能在军备竞赛中实现自动化，而编剧不能，那么你每次都能获胜。

在应用程序前面的apache服务器上编写一个反向代理，实现一个Tarpit (Wikipedia文章)来惩罚机器人。它将简单地管理最近几秒内连接的IP地址列表。您检测到来自单个IP地址的请求爆发，然后在响应之前以指数方式延迟这些请求。

当然，如果多人使用NAT网络连接，他们可以来自同一个IP地址，但人类不太可能介意你的响应时间从2毫秒到4毫秒(甚至400毫秒)，而机器人则会很快受到不断增加的延迟的阻碍。

让机器人用户无利可图，他们很快就会离开——也就是说，偶尔卖一些人类不可能想要的东西(可能是一袋字面上的垃圾)。

我想唯一能做的就是让努力超过垃圾邮件发送者的收益。所以这是一个“头脑风暴”的想法，我不知道如何实现的所有技术细节。我必须做一些研究，但根据我目前的知识，如果其他建议的方法被拒绝，就值得调查一下。

你已经在你的网站上使用flash，那么为什么不使用一个flash控件来协助或完成表单提交呢?控件可以使用密钥对或其他算法与web服务器进行加密通信来散列值?

我想整个形式可以在闪光?就我个人而言，我会使用Java小程序，因为那是我最喜欢的语言。

目标的一个可能的解决方案，不一定是问题的标题:

Instead of serving up the special deal to everyone, serve it to random sets of ip addresses at a time. For instance, partition the IP space into 256 unique blocks, and at time=0, only allow people with ip addresses in the first block, and at time=5 seconds, allow people from the first block and the second block... until the last time slot arrives, and allow everyone to see the deal. One idea to randomize it would be to take the least significant bits of the md5/sha of their IP plus some salt based on the deal.

这将允许脚本编写人员拥有接近于零的响应时间，以及拥有多个ip地址的优势，但这将意味着给定的机器人与其他因ip地址而比他们“幸运”的客户相比没有任何优势。

将这一点与其他一些想法结合起来似乎是个好主意。

首先，让我回顾一下我们需要做的事情。我意识到我只是在转述最初的问题，但重要的是我们要百分之百地理解这个问题，因为有很多很好的建议，4个中有2个或3个是正确的，但正如我将演示的那样，您将需要一个多方面的方法来满足所有的需求。

要求1:摆脱“机器人抨击”:

首页的快速“猛击”正在损害网站的性能，这是问题的核心。这种“猛击”既来自单ip机器人，也可能来自僵尸网络。我们想把两者都去掉。

要求二:不要破坏用户体验:

我们可以通过实施一个讨厌的验证程序来有效地解决机器人的情况，比如打电话给操作员，解决一堆验证码，或类似的问题，但这就像强迫每个无辜的飞机乘客跳过疯狂的安全圈，只是为了抓住最愚蠢的恐怖分子的渺茫机会。哦，等等，我们真的这么做了。但让我们看看在woot.com上能否做到这一点。

要求三:避免“军备竞赛”

正如您所提到的，您不希望卷入垃圾邮件机器人军备竞赛。因此，您不能使用隐藏或混乱的表单字段、数学问题等简单的调整，因为它们本质上是可以简单地自动检测和规避的模糊度量。

需求4:挫败“警报”机器人:

这可能是您的要求中最困难的。即使我们可以进行有效的人类验证挑战，机器人仍然可以在你的首页上投票，并在有新报价时提醒编剧。我们也想让那些机器人变得不可行。这是第一个需求的更强版本，因为机器人不仅不能发出破坏性能的快速请求——它们甚至不能发出足够多的重复请求来及时向脚本人员发送“警报”以赢得报价。

---

好，让我们看看是否能满足这四个条件。首先，正如我提到的，没有一种测量方法能达到目的。你将不得不结合一些技巧来实现它，你将不得不忍受两个烦恼:

少数用户将被要求经历重重考验 少数用户将无法获得特别优惠

我知道这些都很烦人，但如果我们能让“小”的数字足够小，我希望你会同意利大于弊。

第一个措施:基于用户的节流:

这个很简单，我相信你已经做过了。如果用户已登录，并保持每秒刷新600次(或其他)，您将停止响应并告诉他冷却。事实上，你可能会更早地限制他的请求，但你明白我的意思。这样，一个登录的机器人将被禁止/节流一旦它开始投票你的网站。这是简单的部分。那些未经验证的机器人才是我们真正的问题，下面就来谈谈它们:

第二个措施:某种形式的知识产权限制，正如几乎所有人都建议的那样:

No matter what, you will have to do some IP based throttling to thwart the 'bot slamming'. Since it seems important to you to allow unauthenticated (non-logged-in) visitors to get the special offers, you only have IPs to go by initially, and although they're not perfect, they do work against single-IP bots. Botnets are a different beast, but I'll come back to those. For now, we will do some simple throttling to beat rapid-fire single-IP bots. The performance hit is negligable if you run the IP check before all other processing, use a proxy server for the throttling logic, and store the IPs in a memcached lookup-optimized tree structure.

第三种方法:用缓存的响应掩盖油门:

With rapid-fire single-IP bots throttled, we still have to address slow single-IP bots, ie. bots that are specifically tweaked to 'fly under the radar' by spacing requests slightly further apart than the throttling prevents. To instantly render slow single-IP bots useless, simply use the strategy suggested by abelenky: serve 10-minute-old cached pages to all IPs that have been spotted in the last 24 hours (or so). That way, every IP gets one 'chance' per day/hour/week (depending on the period you choose), and there will be no visible annoyance to real users who are just hitting 'reload', except that they don't win the offer. The beauty of this measure is that is also thwarts 'alarm bots', as long as they don't originate from a botnet. (I know you would probably prefer it if real users were allowed to refresh over and over, but there is no way to tell a refresh-spamming human from a request-spamming bot apart without a CAPTCHA or similar)

第四项措施:

You are right that CAPTCHAs hurt the user experience and should be avoided. However, in _one_ situation they can be your best friend: If you've designed a very restrictive system to thwart bots, that - because of its restrictiveness - also catches a number of false positives; then a CAPTCHA served as a last resort will allow those real users who get caught to slip by your throttling (thus avoiding annoying DoS situations). The sweet spot, of course, is when ALL the bots get caught in your net, while extremely few real users get bothered by the CAPTCHA. If you, when serving up the 10-minute-old cached pages, also offer an alternative, optional, CAPTCHA-verified 'front page refresher', then humans who really want to keep refreshing, can still do so without getting the old cached page, but at the cost of having to solve a CAPTCHA for each refresh. That is an annoyance, but an optional one just for the die-hard users, who tend to be more forgiving because they know they're gaming the system to improve their chances, and that improved chances don't come free.

第五种方法:诱饵废话:

Christopher Mahan had an idea that I rather liked, but I would put a different spin on it. Every time you are preparing a new offer, prepare two other 'offers' as well, that no human would pick, like a 12mm wingnut for $20. When the offer appears on the front page, put all three 'offers' in the same picture, with numbers corresponding to each offer. When the user/bot actually goes on to order the item, they will have to pick (a radio button) which offer they want, and since most bots would merely be guessing, in two out of three cases, the bots would be buying worthless junk. Naturally, this doesn't address 'alarm bots', and there is a (slim) chance that someone could build a bot that was able to pick the correct item. However, the risk of accidentally buying junk should make scripters turn entirely from the fully automated bots.

第六项措施:僵尸网络节流:

(删除)

Okay............ I've now spent most of my evening thinking about this, trying different approaches.... global delays.... cookie-based tokens.. queued serving... 'stranger throttling'.... And it just doesn't work. It doesn't. I realized the main reason why you hadn't accepted any answer yet was that noone had proposed a way to thwart a distributed/zombie net/botnet attack.... so I really wanted to crack it. I believe I cracked the botnet problem for authentication in a different thread, so I had high hopes for your problem as well. But my approach doesn't translate to this. You only have IPs to go by, and a large enough botnet doesn't reveal itself in any analysis based on IP addresses.

所以你知道了，第六小节是零。没什么。邮政编码。除非僵尸网络很小，或者足够快，可以被通常的IP限制，否则我不认为有任何有效的措施可以对抗僵尸网络，而不涉及明确的人类验证，如CAPTHAs。我很抱歉，但我认为结合以上五种方法是你最好的选择。你可能只需要abelenky的10分钟缓存技巧就可以了。

用户必须等待图像中显示的延迟的延迟页面如何?

你只有在他们在图像中指定的足够短的时间内点击时才会从他们到达的页面进行排序，也许图像可以在动画gif或非常小的javascript或flash计时器中进行倒计时。

如果他们在时间限制之外跳转到详细信息页面，他们会看到在之前的回答中讨论过的昂贵物品。

对未注册用户延迟5分钟发布所有产品公告。休闲用户不会真正注意到这一点，而非休闲用户还是会注册。

我不能百分之百地确定这是否可行，至少不尝试一下是不行的。

But it seems as if it should be possible, although technically challenging, to write a server-side HTML/CSS scrambler that takes as its input a normal html page + associated files, and outputs a more or less blank html page, along with an obfuscated javascript file that is capable of reconstructing the page. The javascript couldn't just print out straightforward DOM nodes, of course... but it could spit out a complex set of overlapping, absolute-positioned divs and paragraphs, each containing one letter, so it comes out perfectly readable.

机器人将无法阅读它，除非它们使用完整的渲染引擎和足够的人工智能来重建人类将看到的内容。

然后，因为这是一个自动化的过程，您可以根据您的计算能力经常重新打乱站点-每分钟，或每十分钟，或每小时，甚至每次页面加载。

当然，写这样一篇含糊不清的文章会很困难，而且可能不值得。但这只是一个想法。

没有完全修复，但我在这里还没看到。

跟踪“砰”的地址，并张贴免责声明，说BOC/物品将不会被运送到任何不遵守你的TOS的地址。

这将对一些人产生心理影响，而其他想要利用您的站点的人将不得不切换方法，但您将否定他们的一个途径。

这样怎么样:创建一个表单，如果有新商品正在出售，就会收到一封电子邮件，并添加一个捕捉系统，将相同的内容发送给任何在X秒内刷新的人。

这样你就赢得了所有的场景:你摆脱了刮刮器(他们可以刮掉他们的电子邮件帐户)，你给了那些不会在你的网站上买东西的人机会!如果我真的想买东西，我肯定会在我的手机里收到电子邮件并登录购买。

这里有很多建议，所以如果这已经发布了，请原谅我。

我要做的第一件事是把订购分成两步。第一步将在记录IP地址时传回一个GUID。第二步将接收GUID，并将其与已记录的IP地址进行比较。结合阻止垃圾邮件的IP地址(IE:比人类点击刷新的速度还快)，这种技术可以阻止垃圾邮件发送者成功购买，从而解决1和3。

第二项是有问题的，但我会保持一个常规用户IP地址的运行列表，并限制任何新用户的流量。这可能会让首次访问者和拨号用户(由于IP地址的变化)受到冷落，但我认为这只是通过优先考虑回头客而在糟糕的情况下做出最好的选择……而拨号用户，即使没有任何垃圾邮件发送者，他们是否会“获胜”也是值得怀疑的。

你们为什么不封杀那些被你们认定为机器人的用户的信用卡呢?

在你的网站上发布使用机器人是非法的 找到识别机器人的某些启发式方法(例如，可以通过短期IP跟踪或通过它们检查表单所需的时间来完成) 如果你标记为机器人的人购买了该商品，冻结他的信用卡以备将来使用 下次他想买东西的时候，不让他买，把商品退回库存

我想即使是专业人士最终也会用完信用卡的。

一旦装瓶者放弃你，你的服务器负载就会随着时间而减少。另一个想法是在不同的服务器之间分离页面——例如，RSS提要在一个服务器上，主页在另一个服务器上，结帐在另一个服务器上。

祝你好运。

如上所述，我在非验证码表单上做了一些工作，方法是使用存储在表单中的结果的预期值的预计算散列。这个想法适用于Wordpress的两个反垃圾邮件插件:WP-Morph和WP-HashCash。唯一的缺点是客户端浏览器必须能够解释JavaScript。

你怎么知道有编剧在下命令?

问题的关键在于您无法将脚本编写者与合法用户分开，因此无法阻止他们，那么您是如何知道存在脚本编写者的呢?

如果您有办法回答这个问题，那么您就有了一组可以用来筛选脚本程序的特征。

所以你的问题是生意太多了?有人在抢你的生意?这是假设这些编剧能产生合格的销售吗?问题是他们抢在别人之前把你的产品抢购一空?

你为“脚本”创建一个完整的web服务API如何?然后给他们一点折扣或额外津贴，让他们遵守你的规则。你的业务翻倍，有你的网络销售和API销售。

要么这样做，要么获得更多的库存——你无法对抗它——拥抱并适应它。

我很确定你的服务器已经记录了所有传入请求的ip(大多数都是这样)——所以数据已经在那里了。

也许你可以:

只需验证“获胜者”，验证它的IP在日志中显示的值小于某个阈值(我使用“grep | wc -l”来获得计数)。如果它超过你的阈值，暂时阻止该IP(一个小时左右?)

取消任何与“上一位”中奖者有相同收货地址或付款信息的“中奖者”的资格，或者在一定时间内中奖的“中奖者”，以分散“中奖”。

机器人不会把他们弄到那里的。

把刮刀惹毛: 当“随机垃圾”条目出现时，通过“代码混淆器”运行该页面的HMTL输出……这不会改变页面的“显示”…只是用随机生成的id打乱代码等。

更阴险的:

根据获胜IP在日志中出现的次数，增加“获胜”项目的价格。即使机器人赢了，你也赢了。: -)

Trying to target the BOTs themselves will never solve the problem - whoever is writing them will figure out a new way around whatever you've put in place. However forcing the user to think before buying would be a much more effective solution. The best way of doing this that I can think of is run a Dutch auction. Start the price high (2x what you buy it for in the shop) and decrease it over time. The first person to hit buy gets it. I don't think any bot is intelligent enough to workout what the best price is for the item.

Restrict the times at which you release offers: For example: only from 7 minutes to 8 minutes past the start of an hour. Do not deviate from this, and give penalties on the order of a couple seconds to IPs which check a lot in the half hour before the release time. It then becomes advantageous for bot owners to only screen scrape for a couple minutes every hour instead of all. the. time. Also, because a normal person can check a site once every hour but not every second, you put normal people on a much more even footing with the bots.

饼干: 使用仅由唯一ID(数据库表的键)组成的跟踪cookie。对没有cookie的客户端、无效cookie、使用新IP的相同cookie的客户端或频繁使用cookie的客户端给予“发布延迟”。

识别可能的机器人: cookie将导致机器人为它们控制的每个IP请求多个cookie，这是可以跟踪的行为。只有一个发出的cookie的ip很可能是普通的客户端。有许多发出cookie的ip要么是大型NAT-ed网络，要么是一个机器人。我不知道你会如何区分这些，但公司可能更有可能拥有DNS服务器、网页之类的东西。

也许你需要一种解决方案，让机器人完全无法区分垃圾销售和所有其他内容。

这是验证码主题的一种变体，但不是用户通过解决验证码来验证自己，验证码是销售的描述，以一种视觉上令人愉悦的方式呈现(但可能有些被背景掩盖)。

将道具卖给非脚本人。 不要让“正常”用户完成任何任务来证明他们是人类。

所以基本上你想知道一个特定的用户是否是一个人，而不需要他们证明。据我所知，这在网上是不可能的，抱歉。

我建议将机制改为拍卖。

以下是我的看法。攻击机器人所有者的投资回报率，这样他们就会做你想让他们做的合法事情，而不是欺骗。让我们从他们的角度来看。他们的资产是什么?显然，无数的一次性机器、IP地址，甚至可能还有大量不熟练的人愿意做无聊的工作。他们想要什么?总是在其他合法的人得到它之前得到你提供的特别交易。

The good news is that they only have a limited window of time in which to win the race. And what I don't think they have is an unlimited number of smart people who are on call to reverse engineer your site at the moment you unleash a deal. So if you can make them jump through a specific hoop that is hard for them to figure out, but automatic for your legitimate customers (they won't even know it's there), you can delay their efforts just enough that they get beat by the massive number of real people who are just dying to get your hot deal.

The first step is to make your notion of authentication non-binary, by which I mean that, for any given user, you have a probability assigned to them that they are a real person or a bot. You can use a number of hints to build up this probability, many of which have been discussed already on this thread: suspicious rate activity, IP addresses, foreign country geolocation, cookies, etc. My favorite is to just pay attention to the exact version of windows they are using. More importantly, you can give your long-term customers a clear way to authenticate with strong hints: by engaging with the site, making purchases, contributing to forums, etc. It's not required that you do those things, but if you do then you'll have a slight advantage when it comes time to see special deals.

Whenever you are called upon to make an authentication decision, use this probability to make the computer you're talking to do more-or-less work before you will give them what they want. For example, perhaps some javascript on your site requires the client to perform a computationally expensive task in the background, and only when that task completes will you let them know about the special deal. For a regular customer, this can be pretty quick and painless, but for a scammer it means they need a lot more computers to maintain constant coverage (since each computer has to do more work). Then you can use your probability score from above to increase the amount of work they have to do.

To make sure this delay doesn't cause any fairness problems, I'd recommend making it be some kind of encryption task that includes the current time of day from the person's computer. Since the scammer doesn't know what time the deal will start, he can't just make something up, he has to use something close to the real time of day (you can ignore any requests that claim to come in before the deal started). Then you can use these times to adjust the first-come-first-served rule, without the real people ever having to know anything about it.

The last idea is to change the algorithm required to generate the work whenever you post a new deal (and at random other times). Every time you do that, normal humans will be unaffected, but bots will stop working. They'll have to get a human to get to work on the reverse-engineering, which hopefully will take longer than your deal window. Even better is if you never tell them if they submitted the right result, so that they don't get any kind of alert that they are doing things wrong. To defeat this solution, they will have to actually automate a real browser (or at least a real javascript interpreter) and then you are really jacking up the cost of scamming. Plus, with a real browser, you can do tricks like those suggested elsewhere in this thread like timing the keystrokes of each entry and looking for other suspicious behaviors.

So for anyone who you know you've seen before (a common IP, session, cookie, etc) you have a way to make each request a little more expensive. That means the scammers will want to always present you with your hardest case - a brand-new computer/browser/IP combo that you've never seen before. But by putting some extra work into being able to even know if they have the bot working right, you force them to waste a lot of these precious resources. Although they may really have an infinite number, generating them is not without cost, and again you are driving up the cost part of their ROI equation. Eventually, it'll be more profitable for them to just do what you want :)

希望这对你们有帮助，

Eric

hashcash使用。

Hashcash是一种拒绝服务计数器度量工具。它目前的主要用途是帮助hashcash用户避免由于基于内容和基于黑名单的反垃圾邮件系统而丢失电子邮件。

我认为你最好的选择是关注即将到来的IP，但要从几个方面缓解你提到的问题。首先，使用概率散列(例如，Bloom Filter)来标记之前见过的IP。这类算法非常快，并且可以很好地扩展到绝对庞大的集合大小。其次，使用渐变响应，即服务器延迟添加到每个请求中，根据您“最近”看到该IP的次数来预测。

At the expense of Usability by those with screen readers you could just, on 90% of the pages use unlabelled, undenotable picture buttons. Rotate the pictures regularly and use a random generator and random sorting to lay out two buttons that say "I want this" and "I am a bot". Place them side by sort in a different order. At each stage a user can make progress torwards their target but a bot is more likely to make a mistake (50% * number of steps). It's like a capture at every stage on easier for the user and slower for bots who need to prompt their master at EVERY single step. Put the price, the confirm button, the item description in pictures. It sucks but likely more successful.

为什么不将内容设置为CAPTCHA?

On the page where you display the prize, always have an image file in the same location with the same name, when a bag o crap sale is on, dynamically generate and load an image with the text etc advertising the prize, when no sale is on just have some default image that integrates well with the site. Seems like its the same concept as CAPTCHA... if the bot cannot figure out the meaning of the image they will not be able to "win" it, if they can they would have been able to figure out your CAPTCHA images anyways.

让机器人在公平的场地上竞争。加密时间戳并将其粘贴在隐藏表单字段中。当您收到提交文件时，解密它并查看已经过了多长时间。如果它超过了人类打字能力的阈值，则拒绝它。现在机器人和人类只能以同样的速度购买这袋垃圾。

如果你不能打败他们……改变规则!

为什么不提供一个比编剧为自己创造的更好的系统呢? 修改你的网站，让不使用机器人脚本的人更公平。人们注册(CAPTCHA或电子邮件验证)，并有效地进入彩票比赛中获胜!

“获胜”让游戏更有趣。每个人支付一小笔报名费，获胜者就能以更低的价格获得产品

我不是一个网页开发人员，所以对此持保留态度，但这是我的建议-

每个用户都有一个cookie(包含一串随机数据)，决定他们是否看到当前的垃圾销售。

(如果你没有饼干，你就看不到它们。因此，不启用cookie的用户永远不会看到糟糕的销量;新用户在第一次浏览页面时永远不会看到它们，但之后会看到)。

每次用户刷新网站时，他都会将当前的cookie传递给服务器，服务器会根据这个cookie来决定是给他一个新的cookie还是保持当前的cookie不变;并以此为基础，决定是否在页面上展示垃圾促销。

为了保持服务器端的简单性，你可以说在任何时候，只有一个cookie会让你看到糟糕的销售情况;还有一些其他的cookie被标记为“在最近2秒内生成的”，这些cookie将始终保持不变。因此，如果刷新页面的速度快于此，则无法获得新的页面。

(…啊，好吧，我想这并不能阻止机器人恢复旧的饼干并把它传给你。不过，也许在某个地方还是有解决方案的。)

停止所有的机器人将是相当困难的，特别是没有使用验证码。我认为您应该从实现各种各样的措施的立场来处理这个问题，使脚本编写人员的生活更加困难。

我相信这是一项可以淘汰其中一些人的措施:

您可以尝试为每个响应随机分配标记的id和类名。这将迫使机器人依赖于重要标签的位置和上下文，这需要一个更复杂的机器人。此外，如果你想在CSS中使用相对或绝对定位，你可以随机化标签的位置。

这种方法最大的缺点是，你必须采取措施确保你的CSS文件不是客户端缓存的，因为它当然需要包含随机的id和类名。克服这一问题的一种方法是不使用外部CSS文件，而是将CSS与随机选择器放在页面的<head></head>部分中。这将允许随机化的CSS与页面的其余部分一起被客户端缓存。

步骤:

(结合了另一张海报和GIF垃圾邮件制造者的想法)

显示整个提供页面的图像，广告文案和所有。 加密URL中的价格。

攻击:

Bots going to the URL to view the price on the checkout page turn the checkout price tag into an image, or apply a captcha before users can go to the order page. chewing up bandwidth Serve special offers using images, normal offers using HTML. reckless bot ordering some of the special "image" offers are actually at normal prices. RSS Scraping RSS feeds must be paid for by hashcash or captchas. This has to be on a per-request basis. It can be pre-paid, for instance user can enter 20 captchas for 200 RSS look ups Once the threat of DDOS has been mitigated, you can implement e-mail notification of offers

想出一种识别机器人的方法如何，可能是基于IP，但不阻止他们访问网站，只是不允许他们实际购买任何东西。也就是说，如果他们买了，他们实际上并没有得到它，因为机器人违反了使用条款。

CAPTCHA的问题在于，当你在Woot上看到垃圾促销时，作为消费者，如果你希望收到你的垃圾包，你就必须迅速采取行动。所以，如果你要使用一种形式的验证码，对客户来说必须非常快。

What if you had a large image, say 600 x 600 that was just a white background and dots of different colors or patterns randomly placed on the image. The image would have an image map on it. This map would have a link mapped to small chunks of the image. Say, 10 x 10 blocks. The user would simply have to click on the specific type of dot. It would be quick for end the user and it would somewhat difficult for a bot developer to code. But this alone may not be that difficult for a good bot creator to get past. I would add ciphered URLs.

以前我在开发一个系统，可以对url进行加密。如果这些页面上的每个URL都用随机的IV加密，那么它们对机器人来说都是唯一的。我设计这个是为了迷惑探测机器人。我还没有完成的技术，但我有一个小网站编码，功能在这个庄园。

虽然这些建议并不是一个完整的解决方案，但它们会使构建一个工作机器人变得更加困难，同时仍然易于人类使用。

可能没有好的解决方案，只要这袋垃圾的意外分布只与一个时间点挂钩——因为机器人有足够的时间和资源，以短时间间隔不断撞击网站。

我认为你必须添加一个额外的标准，即机器人不能从它们的一端进行屏幕抓取或操作。例如，在任何时候，有5000人每分钟多次访问页面，寻找这袋垃圾，每秒钟有50个机器人敲打页面。在它出现后的几秒钟内，50个机器人就会把它抢购一空。

因此，您可以添加一个条件，即垃圾首先出现在任何用户的整数IP的模量30是一个随机数，比如17。也许每秒钟都会添加一个随机数，所以这些废话会在30秒内逐步向所有客户端显示。

现在想象一下前几秒钟会发生什么:目前，所有50个机器人都能立即抢购所有垃圾，而人类得到0。在这个方案下，6秒后只有10个机器人通过了，而1000个人类通过了，大部分垃圾都流向了人类。你可以根据用户数量和可用单位调整时间和随机模数来优化间隔。

Not a perfect solution, but an improvement. The upside is many more humans than bots will benefit. There are several downsides, mainly that not every human gets an equal shot at the crap on any particular day - though they don't have much of a shot now, and I'd guess even without bots, most of them get shut out at random unless they happen to refresh at just the right second. And, it wouldn't work on a botnet with lots of distributed IPs. Dunno if anyone's really using a botnet just for woot crap though.

你的最终目标是让更多的用户购买你的产品。

如果您在一两个小时内释放w00t包，并在一系列IP地址上释放它们，而不是同时将它们释放到任何IP地址，会怎么样呢?

假设你有255袋w00t。1.0.0.0可以在第一分钟购买，2.0.0.0可以在第二分钟购买(可能有2袋w00t可用)，等等。

然后，在255分钟之后，你已经为每个人提供了几袋w00t，尽管很可能不是所有255袋w00t都剩下了。

这将真正的攻击限制在拥有>255台计算机的用户，尽管机器人用户可能能够“拥有”分配给他们的IP范围的w00t包。

没有要求你匹配包的IP公平(你肯定应该使用某种类型的MD5 /随机种子的东西)…如果你增量地分配10袋w00t，你只需要确保它在你的人群中均匀地分配。

如果IP不好，那么您可以使用cookie，并排除向未经过cookie的用户提供一袋w00t的用例。

如果您注意到某个特定的IP、cookie或地址范围具有非常大的流量，请按比例在稍后/最后向它们提供w00t包，以便偶尔/稳定/缓慢的访问者在重度/快速/可能的bot用户之前获得机会。

——罗伯特。

让我们换个角度看问题——你让机器人买你想让真人买的东西，那给机器人一个机会买你不想让真人买的东西怎么样?

有一个随机的机会，一些非显示的html，抓取机器人会认为是真实的情况，但现实的人不会看到(不要忘记，现实的人包括盲人，所以考虑屏幕阅读器等)，这通过购买一些非常昂贵的东西(或不进行实际购买，但获得付款细节，让你放在列表上)。

即使机器人切换到“提醒用户”而不是“购买”，如果你能得到足够多的假警报，你可能就能让人们(也许不是所有人，但减少一些诈骗总比没有强)不去打扰它。

我不知道是否有人建议这样做，但与其保留机器人的IP列表，还不如设置一个cookie或会话变量来跟踪机器人呢?下面是一个PHP的例子:

<?php
// bot check
$now = microtime(true);
// bot counter var
$botCounter = 0;
if (array_key_exists('botCheck_panicCounter', $_REQUEST))
{
  $botCounter = $_REQUEST['botCheck_panicCounter'];
}

// if this seems to be a bot
if ($botCounter > 5)
{
  die('Die()!!');
}

// if this user visited before
if (array_key_exists('botCheck_lastVisit', $_REQUEST))
{
  $lastVisit = $_SESSION['botCheck_lastVisit'];
  $diff = $now - $lastVisit;

  // if it's less than a second
  if ($diff < 1)
  {
    // increase the bot counter
    $botCounter += 1;
    // and save it
    $_REQUEST['botCheck_panicCounter'] = $botCounter;
  }
}

// set the var for future use
$_SESSION['botCheck_lastVisit'] = $now;

// ---------------
// rest of the content goes here
?>

我没有检查语法错误，但您可以理解。

我建议使用基于防火墙的解决方案。Netfilter/iptables与大多数防火墙一样，允许您设置单位时间内新页面请求的最大数量。

例如，为了限制分配给人类的页面视图的数量——比如说，每30秒6次请求——你可以发布以下规则:

iptables -N BADGUY
iptables -t filter -I BADGUY -m recent --set --name badguys

iptables -A INPUT -p tcp --dport http -m state --state NEW -m recent --name http --set
iptables -A INPUT -p tcp --dport http -m state --state NEW -m recent --name http --rcheck --seconds 30 --hitcount 6 -j BADGUY
iptables -A INPUT -p tcp --dport http -m state --state NEW -m recent --name http --rcheck --seconds  3 --hitcount 2 -j DROP

请注意，此限制将独立应用于每个访问者，因此一个用户滥用网站不会影响其他访问者。

希望这能有所帮助!

您可以通过同时更新RSS和HTML来减少服务器上的负载，这样机器人就不会对您的站点进行屏幕抓取。当然，这给了机器人和购买你的装备的优势。

如果你只接受信用卡支付(可能是这样，也可能不是，但这显示了我的思路)，只允许用户每10次使用同一个账户和/或信用卡购买一次BOC。对一个脚本小子来说，搞到一大堆ip很容易，但搞到一大堆信用卡就不那么容易了。正如你所说的，ip很难被禁止，而暂时禁止信用卡应该是在公园里散步。

你可以让每个人都知道限制是什么，或者你可以告诉他们，因为高需求和/或机器人的兴趣，在不具体说明机制的情况下，对购买实施了限制。

在节流期间的每一次购买尝试都可能引发指数级的倒退——你买了一个BOC，在你再次尝试之前，你必须通过10次销售。不管怎样，你还是会在下一次促销时再次尝试，现在你不得不等待20次、40次、80次……

只有在人类用户不太可能在不到10次销售中获得两次BOC的情况下，这才真正有用。适当地调整数字。

根据您想要进入的复杂程度，您可以采取一些解决方案。

这些都是基于IP跟踪，在僵尸网络和云计算下有些崩溃，但应该能挫败绝大多数的僵尸。乔·兰登拥有大量机器人的可能性远远低于他只是运行一个从某处下载的Woot机器人来获取他的垃圾的可能性。

普通的节流

At a very basic, crude level, you could throttle requests per IP per time period. Do some analysis and determine that a legitimate user will access the site no more than X times per hour. Cap requests per IP per hour at that number, and bots will have to drastically reduce their polling frequency, or they'll lock themselves out for the next 58 minutes and be completely blind. That doesn't address the bot problem by itself, but it does reduce load, and increases the chance that legitimate users will have a shot at the item.

自适应调节

An variant on that solution might be to implement a load balancing queue, where the number of requests that one has made recently counts against your position in the queue. That is, if you keep slamming the site, your requests become lower priority. In a high-traffic situation like the bag of crap sales, this would give legitimate users an advantage over the bots in that they would have a higher connection priority, and would be getting pages back more quickly, while the bots continue to wait and wait until traffic dies down enough that their number comes up.

废料验证码

Third, while you don't want to bother with captchas, a captcha at the very end of the process, right before the transaction is completed, may not be a bad idea. At that point, people have committed to the sale, and are likely to go through with it even with the mild added annoyance. It prevents bots from completing the sale, which means that at a minimum all they can do is hammer your site to try to alert a human about the sale as quickly as possible. That doesn't solve the problem, but it does mean that the humans have a far, far better chance of obtaining sales than the bots do currently. It's not a solution, but it's an improvement.

以上的组合

实施基本的、慷慨的限制来阻止最滥用的机器人，同时考虑到单个公司IP背后的多个合法用户的潜力。截止数字将非常高——你引用了bot攻击你的网站10次/秒，即216万次/小时，这显然远远高于任何合法的使用量，即使是最大的公司网络或共享ip。

实现负载平衡队列，这样如果占用的服务器连接和带宽超过自己的份额，就会受到惩罚。这将惩罚共享公司池中的人，但不会阻止他们使用站点，而且他们的违规行为应该远没有您的装瓶者那么可怕，因此他们的惩罚应该不那么严重。

最后，如果您超过了每小时请求的某个阈值(这个阈值可能远远低于“自动断开连接”的截止值)，那么就要求用户使用验证码进行验证。

这样，合法使用网站的用户每小时只有84个请求，即使他们非常兴奋，也不会注意到网站速度变慢了。然而，乔·波特发现自己陷入了两难境地。他可以:

Blow out his request quota with his current behavior and not be able to access the site at all, or Request just enough to not blow the request quota, which gives him realtime information at lower traffic levels, but causes him to have massive delays between requests during high-traffic times, which severely compromises his ability to complete a sale before inventory is exhausted, or Request more than the average user and end up getting stuck behind a captcha, or Request no more than the average user, and thus have no advantage over the average user.

只有滥用的用户才会受到服务降级或复杂性增加的影响。合法用户不会注意到任何变化，除了他们更容易购买他们的垃圾包。

齿顶高

以远低于注册用户的速率限制未注册用户的请求。这样，机器人所有者就必须通过一个经过身份验证的帐户来运行机器人，以通过应该是相对严格的节流率。

然后，有创造力的装瓶者将注册多个用户id，并使用这些id来实现他们想要的查询率;您可以通过将给定时间段内来自同一IP的任何ID视为相同的ID，并接受共享节流来解决这个问题。

这使得装瓶商别无选择，只能运行一个机器人网络，每个IP一个机器人，每个机器人注册一个Woot账户。不幸的是，这实际上无法与大量未关联的合法用户区分开来。

您可以将此策略与上述一种或多种策略结合使用，目的是为没有滥用使用模式的注册用户提供最佳服务，同时根据他们的状态(匿名或已注册)以及由流量指标决定的滥用程度逐步惩罚其他用户，包括注册用户和未注册用户。

这总是很困难，我为你避免使用验证码的愿望鼓掌。我建议首先根据他们的行为来阻止他们，你可以通过HTTP请求来确定。看看这个被称为“不良行为”的工具，在我在几个网站上使用它的这一年里，它还没有阻止一个真正的人。大多数机器人都不能很好地伪装成一个网络浏览器。我还推荐使用项目蜜罐API。

其次，随机更改表单，包括标签。这不是为了愚弄机器人，这是为了让你发现他们的IP地址/代理。xx次搞砸条目的东西应该在这个列表上。

最后，如果你发现自己处于一个必须使用某种人工验证过程的位置，可以尝试这样的方法:

[ image of a pig ]

The image above is a: [ ] dog  [ ] house [ ] pig

这对人类来说不会很烦人。

简而言之，你的问题没有“一个”解决方案，不要期望100%的成功。把你的目标设定为把烦恼变成无聊的咆哮，你应该能很快做到。

我的第一个想法是，你说机器人正在抓取你的网页，这意味着他们只抓取HTML内容。因此，让您的订单屏幕验证(从http-logs)，报价相关的图形是从bot加载的

开发一个首页组件和购物车，它们不能在浏览器中本机运行。如果你使用Flex/Flash或Silverlight之类的东西，就很难抓取，而且你可以完全控制服务器通信，因此可以完全屏蔽脚本编写者的内容。

只有当机器人用户用无效的信用卡付款时，这才会成为问题。那么，一个非技术的解决方案如何?

只要他们的付款是有效的，就将机器人用户视为普通用户，并确保你有足够的库存来满足总需求。

结果是:销量增加。你做生意是为了赚钱，对吧?

为了保证只向没有脚本的人销售商品，您能否检测到在首页上显示的商品和下达的订单之间不人道的快速响应?这完全改变了延迟策略，而不是人为地通过0.5秒的延迟来限制每个人，而是尽可能快地允许请求，并打击明显是超人的机器人:)

用户点击和做出决定的速度有一些物理限制，通过在所有请求通过后进行检测(而不是故意减慢所有交互)，不会影响非脚本人员的性能。

如果只在某些时间使用验证码是可以接受的，那么可以将延迟时间增加到fast-human(而不是超人)，并且如果有人点击非常快，则要求事后确认验证码。类似于一些网站要求验证码确认，如果有人快速发布多个帖子。

遗憾的是，我不知道有什么好方法来阻止你的产品列表的屏幕抓取:(

我只是想知道有没有简单的解决办法。

我假设表明垃圾销售的消息是通过文本发布的，这就是刮刮器寻找的信息。

如果你用图片来代替广告呢?这样做可能会带来一些设计问题，但它们可以被克服，并可能成为一些巧妙创意的动力。

问题# 1 必须有一些设计空间专门用于图像。(想耍点花招吗?通过这个插槽旋转一个本地广告。当然，图像的名称需要是静态的，以避免给刮刀的气味。这是一个永远不用担心广告盲目性的位置……)

问题# 2 RSS。我不确定是否每个人都可以在他们的提要阅读器中查看图像。如果有足够多的用户可以这样做，那么您可以开始发送包含图像的每日提要更新。你可以在大多数日子里发送任何你想要的杂七杂四的东西，然后根据需要将其切换为你的垃圾销售警报。

我不知道……他们会不会只是编程让他们的机器人在每次feed项目出去的时候都攻击你的网站?

其他问题吗?可能很多。也许这将有助于头脑风暴。

当心 布莱恩

以下是你可以做的一些合理假设:

Any automated solution can and will be broken. Making the site completely require human input (eg CAPTCHA) will greatly increase the difficulty of logging in/checking out/etc. You have a limited number of Bandoliers of Cabbage to sell. You can track users by session via a client-side cookie. You aren't dealing with extremely hardcore criminals here; these are simply technical people who are bending, but not breaking, the law. Successful orders via bots will go to the person's home, and likely not some third-party mail drop.

解决方案不是技术上的。这是一个政策问题。

在web服务器上记录所有客户端会话id。 制定“限制机器人”政策;比如，每X秒刮一次屏幕，让使用普通浏览器的用户能够点击刷新。任何被发现超过这个限制的用户都不会被开除。 接下来，向已知的机器人所有者发送一堆leakfrog。

以下是我的做法:

Require all bidders for bag of crap sales to register with the site. When you want to start a sale, post "BOC sale starting soon, check your email to see if you are eligible" on your main page. Send out invitations to a random selection of the registered players, with a url unique to that particular sale when sale starts. Ensure the URL used is different for each sales event. Tweak the random selection invitation algorithm to pull down elibiblity for frequent winners, based upon Credit Card used for purchase, paypal account, or shipping address.

这可以阻止机器人，因为你的主页只显示未决的BOC事件。机器人在没有收到邮件的情况下无法访问URL，也不能保证他们会收到。

如果你担心销售影响，你也可以通过为每笔销售赠送一到两个BOC来激励参与者。如果你在给定的时间间隔内没有看到足够的宣传，你会自动邮寄额外的注册用户，增加每个宣传的参与者池。

中提琴。公平的竞争环境，没有大量的启发式和网络流量分析。系统仍然可以通过设置大量电子邮件帐户的人来游戏，但通过CC#， paypal帐户，送货地址来调整参与者选择标准可以缓解这一点。

首先，不要试图用技术来打败技术。

你的问题:

网站的可用性 列出使网站令人兴奋和有趣的内容 由脚本导致的服务器负载。

你的目标:

保持网站运行的速度不被机器人减慢。 将道具卖给非脚本人。 不要让“正常”用户完成任何任务来证明他们是人类。

目标#1:保持网站运行的速度不被机器人减慢。

这其实很简单。让其他人托管页面。首页不是托管在服务器上，而是由Amazon S3 / Akamai托管页面。无论如何，页面的大部分都是“静态的”。每5分钟左右重新生成页面，以刷新更动态的项目。(如果你想的话，可以每1分钟重新生成一次)。但是现在这些机器人攻击的不是你的服务器，而是Akamai的CDN，它当然可以承担负载。

当然，RSS订阅也可以这样做。没有理由其他服务不能为你承担带宽/负载的冲击。在相关的说明中，所有的图像都由Akamai等提供。为什么要承担这个责任?

目标#2:将道具卖给非脚本人员

我同意其他人的意见，让脚本没有真正的优势。然而，编写脚本也是一个热情的客户的标志，所以你也不想成为一个*洞。

所以我会说，让他们购买，但让他们支付一个膨胀的金额(或者更好)，只是放慢他们的速度，这样其他人就有机会了。

所以每当用户访问网站时，就会以29.99美元的价格提供这袋垃圾，并有一个计时器以随机速度降低或提高价格。有一个图像或其他指标，告诉人们如果他们有耐心，价格是否会下降。

用户有一个“立即购买”按钮，当他们看到价格/#商品是他们想要的时，他们就会点击这个按钮。

例子:

用户:

0秒$29.99(1件)图像 说:“等待一个更低的价格!” 7秒$31.99(1件)图像 说:“等待一个更低的价格!” 13秒$27.99(1项)图像 说:“我打赌你能做得更好!” 16秒1.99美元(0件物品 你会傻到付钱给我们吗 没有什么!” 21秒$4.99(两件物品 说:“越来越好了!” 24秒$4.99 (tres itemos 他说:“没有比这更好的了 箭!” 26秒$8.99(2项)图像 说:“我打赌你能做得更好!”

重复……

在一个逐渐收紧的周期中，正确的“$4.99 (tres itemos)”会显示出来

如果机器人点击刷新，循环就会重新开始。如果用户错过并选择了错误的道具/价格，你便需要决定是否让他们以该价格购买游戏。

例如，如果他们“过度消费”，他们为3件物品支付24.99美元，woot只会向他们收取4.99美元，然后在下次woot购买时提供20美元的优惠券。

目标#3:不要让“普通”用户完成任何任务来证明他们是人类。

你在这里犯了一个逻辑谬误。你假设任何图灵测试(http://en.wikipedia.org/wiki/Turing_test)都是恼人的。这不是真的!

以下是一些建议:

Create a game. The reward for playing the game is a $5 off coupon on the next order. Pair up 2 random users and have them chat with each other. Each user is told to answer 2 questions to the other user : "Ask what color is the your hair ?" and "What are you going to do next weekend?" Some users get paired with a woot random sentence generator. Each user is then asked if the other user is a human. If a user says the woot random sentence generator is human then reply "No I am not and may be you are from Mars as well. Do you want to try again?" Simple flash game that requires the user to maneuver through an obstacle course to get a discount coupon. Ask what city they are in. The reverse geo-code the ip address to see if they are close to being correct. Ask silly questions - "Do you think John McCain is a great president?" "Whose picture is on your driver's license?"

只问三次，因为你真正想做的是放慢脚本节奏。

ASP.net AJAX控件工具包中的NoBot控件呢?

它做了一些自动javascript请求和计时技巧，以防止机器人在没有用户交互的情况下访问网站。

抱歉，如果这不符合要求，我得打个电话 tl;博士> D

将页面的某些部分转换为图像，这样机器人就无法理解它们。

例如，创建整数0-9、美元符号和小数点的小图像。当页面加载时将图像缓存到客户端计算机上…然后显示价格使用通过运行服务器端代码选择的图像。大多数人类用户不会注意到其中的差别，机器人也不知道任何商品的价格。

作为一个长期的WOOTer，我的看法

我很高兴在订购时有一个验证码，只对BOC打开。我想大多数观众都会同意。此外，99.9%的情况下你甚至没有进入订单界面，因为它卖得太快了，所以几乎没有人知道!!

如果你让验证码成为一个非常难的数学问题，我终于可以向我妈妈解释这么多年学习数学的实际好处了。

我不明白为什么IP地址过滤必须是非常昂贵的。使用IIS，您可以构建一个ISAPI过滤器来在本机代码中执行此操作。我相信apache也有类似的接口。使用客户端的IP地址，您可以为HTTP请求编写一个简单的速率限制器，它不依赖于禁止列表或其他类似的废话。

所以问题似乎是:机器人想要他们的“一袋垃圾”，因为它有很高的感知价值，以较低的感知价格。有时候你提供这个道具，机器人就会潜伏，等着看它是否可用，然后它们就会购买这个道具。

既然机器人所有者似乎正在盈利(或潜在盈利)，诀窍就是通过鼓励他们购买垃圾来让他们无利可图。

首先，总是提供“一袋垃圾”。

其次，确保那些废话通常都是废话。

第三，频繁地轮换垃圾。

简单的,不是吗?

你需要一个永久的“为什么我们的垃圾有时是垃圾?”链接，以向人类解释发生了什么。

当机器人看到有垃圾并且自动购买垃圾时，接收者会因为他们花了10美元买了一根坏牙签而非常沮丧。然后是一个空垃圾袋。然后是你鞋底的泥土。

If they buy enough of this crap in a relatively short period of time (and you have large disclaimers all over the place explaining why you're doing this), they're going to lose a fair "bag 'o cash" on your "bag 'o crap". Even human intervention on their part (checking to ensure that the crap isn't crap) can fail if you rotate the crap often enough. Heck, maybe the bots will notice and not buy anything that's been in the rotation for too short a time, but that means the humans will buy the non-crap.

见鬼，你的老客户可能会很开心，因为你可以把这变成一个巨大的营销胜利。开始发布“垃圾”鲤鱼卖了多少。人们会回来看看机器人被咬得有多厉害。

更新:我预计你可能会接到一些投诉电话。我不认为你能完全停止。然而，如果这杀死了机器人，你总是可以停止它，并在以后重新启动它。

限定。将页面浏览量限制在每秒1次不会打扰人类用户。 通过JavaScript链接。简单的机器人不喜欢这个。 至于可用性，统计数据显示，不到1%的用户不使用JS。 2 a。以上的硬核版本。Flash中的链接。 参数存储在会话，而不是在查询字符串。大多数机器人是无状态的。

从没想过我会推荐闪光灯，但是闪光灯呢?不管是不是交易时间，让服务器发送异步加密内容到flash文件信号。只要响应是相同大小的交易或没有交易，机器人就不能分辨它是哪一个。

在更一般的层面上，您需要关注人类和浏览器拥有的资源，而脚本机器人没有，并利用对人类/浏览器来说容易而对机器人来说很难的东西。验证码显然是一个简单的尝试，但不适合你的网站，因为你说。Flash将淘汰大量的机器人，只留下驱动真正浏览器的(较慢的)机器人。解决方案可能比验证码简单得多，如果它只需要用户点击正确的位置。

利用人类的大规模并行图像处理能力!

让浏览网站变得昂贵。

没有办法，我知道，可以保持一个机器人出你的网站。我甚至知道一种服务，有人为你扫描网站。你会怎么处理?

对于机器人来说，最糟糕的事情是，当站点发生变化时。过了一段时间，让机器人继续运行会变得昂贵或无聊。你的网站上可能有更新，看起来像一个新产品，但实际上不是。如果你的更新不规律且不可预测，那么对于机器人来说，事情就会变得非常困难。

禁用IP可能是一种对策，只要它是一个已知的IP。违法者需要使用代理。我所知道的代理工作得很好，但会大大减慢您的速度。

我的想法(我还没有检查所有其他的，所以我不知道它是否新颖)

处理蜂群:

Convert the front-page matter for each day's stuff to be a flash/flex object. Yes, some people will complain, but we're looking for the common case here, not the ideal. You should also randomize the name of your flash objects, so they aren't in any predictable pattern of names. Using Akamai or another CDN, deploy this flash object in advance to the outside world. Akamai produces what appears to be random URLs, so it makes it hard to predict. When it is time for a new sale, you just have to change your URL locally to refer to the appropriate object at Akamai, and people will go fetch the flash object from them to discover if the deal is a BoC or not.

一天结束-你现在有Akamai处理你的午夜交通蜂群

处理购车事宜

Each of the flash objects you create can have lots and lots of content hidden inside - images, links, arbitrary ids, including 'bag of crap' in a thousand places. you should be able to obfuscate the flash as well. When the flash object "goes live", people will start to attack it. But there are so many false positives that a simple string scan is useless - they'll have to simulate running the flash locally. But the flash doesn't write text. It draws lines and shapes. Shapes in different colors, all connected to timers that make them appear and disappear at different times. If you've seen the Colbert Report, you know how the intro has hundreds of words describing Colbert. Imagine something like that for your intro, which will always include Bag O Crap. Now, imagine that the intro takes an arbitrary amount of time - sometimes a few seconds, sometimes as long as a minute or more (make it funny) Meanwhile, "Bag O Crap" is constantly showing up, but again, clearly as part of the intro. Finally, the actual deal of the day is revealed, with an active 'shimmer' effect that makes it difficult for any single snapshot of the canvas to reveal the actual product name. This is floating above an animated background that still says 'bag O crap' and is constantly in motion again, all of this is handled with lines and shapes, not with text strings

最终的结果是——你的黑客被迫拍摄交易的大量图像快照，弄清楚如何分离所有的假阳性和识别实际交易。与此同时，人类只是看着它，由于眼睛疲劳和我们填补文本空白的能力，我们可以原原本本地阅读交易。

这不会永远有效，但会在一段时间内有效。

另一个想法是简单地限制人们购买中行，除非他们以前用该账户购买过东西，并且永远不让他们再购买中行。

我同意上面的海报，他说有时卖的真的是一袋垃圾。

You appear to have come up with a business model which is serverly limited by the technology through which you are trying to deliver it. Yet like most tech minded individuals (not a crticism, after all that is the what this site is for) you are trying to come up with a technical solution. BUT THIS IS A BUSINESS PROBLEM. This is being caused by a failure in the technology, but that does not mean that technology is the answer. And most all solutions that anyone comes up with (and there will be many options) will in the end by bypassed by those determined to 'auto-buy' (for want of a better short description) your 'bags of crap'.

恕我直言，你问了错误的人错误的问题，你将在错误的解决方案上浪费大量的时间和资源。

通过IP或其他机制识别机器人。 总是把那些被识别为机器人的页面放在正常的首页。

被误识别为机器人的真人将得不到这些优惠，但他们也不会注意到。

机器人所有者不会意识到你已经识别了他们，所以他们会停止改编脚本。

我的解决方案是市场变革和技术变革的结合。

目前，销售垃圾促销袋部分的技术方面被处理为正常的woot销售。促销开始了，人们争相购买，所有的商品都卖光了。用于日常销售的相同统计图表都是用过的垃圾销售。

这里涉及到几个市场目标:

Get customers to visit the site once every day (impluse purchasing). The possiblility of a seeing a bag of crap sale is the reason/reward. Network/viral/gossipy effect where a customer sees a bag of crap sale is on they will IM/EMail/Telephone their friends. There is also what I'd call general "good will". Woot is a really cool place because it occasionally rewards its customers with amazing sales (bag of crap that included a flat panel tv)... AND its done in a fair "first comes first served" manner.

前两个似乎是最重要的。纯粹的访客数量会影响正常交易的销售速度(或销售一空)。传统上，新客户主要是通过口口相传来吸引的，让客户把自己的朋友推荐到woot.com是一种胜利。

所以…我的解决方案是将促销活动的递送方式改为更多的抽奖方式。

偶尔用户可以做一些有趣的事情，看看他们是否有资格得到一袋垃圾。有趣的内容可以是类似“punch The monkey”或Orbitz迷你看球游戏、棒球或曲棍球的愚蠢flash游戏。这里的目标是机器人无法编写脚本的游戏，因此需要相当谨慎。我们的目标也不仅仅是给游戏赢家一袋垃圾……但对所有游戏玩家来说。

The technical core of the game is that at the end of the game a request is made to a server that does an "instant lottery" to determine if the user has won a bag of crap sale opportunity. The server request will need to include something calculated by the game itself (roughly speaking "hash cash"... a complex, CPU cycle consuming, calculation, and hopefully one that is difficult to reproduce). This is to prevent a bot from repeatedly entering the lottery just be querying the lottery server/service.

游戏本身也会随着时间而改变。你可以为万圣节、圣诞节、情人节、复活节等制作特殊事件游戏。还有许多有趣的营销理念可以与woot的“wooiness”相匹配。

If the user wins they can purchase N bags of crap (in a time limited window)... but they can also send N friends a time limited invitation to purchase a bag of crap (good for 24 hours). This provides a super strong network effect... customers will definately tell their friends. Or you could also do it as "buy 1 give 1"... let customers buy up to a total of N but force every second one to be shipped to a friend. The key here is to make the network/gossip effect an full fledged part... help the customer tell the world about the wonderfulness of woot.

促销材料周围袋垃圾销售概念也将需要修改。一袋垃圾多快卖完的图表已经无关紧要了。比如每个月人们有多少次机会购买。有多少人告诉他们的朋友。材料应该微妙地强调这一点，每天去拜访是一个好主意。

你也可以宣传为什么一袋垃圾的销售正在改变。尤其是你免费雇佣了最烂的顾问。

Honestly, I think your best solution is to make items during a Woot-Off only be visible to logged in users, and limit each logged-in user to one home page refresh every 500ms or so. (Or possibly make only a picture of the item be visible to unauthenticated users during a Woot-Off, and make sure you don't always use the same picture for Random Crap.) I think Woot users would be willing to accept this if you sell it as a measure to help them get their Bowls of Creaminess, and you can also point out that it'll help them check out quicker. Anything else--even using captchas--is subject to your typical arms race.

构建一个更好的机器人

市场告诉你一些事情。他们想要那袋垃圾。所以与其与脚本斗争(RIAA vs文件共享任何人?)构建一个更好的机器人。

为每个人提供一个安装的应用程序，它与脚本kidide可以组合的任何东西一样好，甚至更好。用户会安装你的品牌应用，而每次出现这种情况。应用程序会自动尝试购买。如果错过了当前的b-o-c，应用程序就有一张“门票”，让它有更好的机会进行下一次b-o-c销售。因此，如果用户滚动自己的脚本，他们就无法获得下一个b-o-c销售的“门票”，而官方应用程序的用户则可以。

在b-o-c销售之间，应用程序可以显示当前出售的物品。见鬼，让用户可以告诉woot应用程序寻找“记忆棒”

当官方的woot b-o-c+脚本应用程序一样好或不好时，谁会构建自己的脚本?

此外，woot还有另一种与客户联系的方式。

你的客户告诉你他们想要什么。

让用户在原价和更高的价格之间做出选择。 你必须找到某种方法，将按钮与它们各自的价格联系起来——颜色、位置，也许还有按钮的“情感内涵”——这很难通过编程来确定，但只需要用户将按钮与价格联系起来。 对用户来说简单，直观，没有麻烦，但对脚本编写人员来说困难，更重要的是，有风险——特别是如果您改变了关联方法。

我同意OP在这里-请不要验证码-这不是一个非常woot的做事方式。

首先设置一些机器人陷阱。我会在主页上更经常地提到BOC，让机器人看起来不智能，所以每次措辞都不同。“中行投诉上升!”所以扫描关键词的机器人会被困住。

然而，我认为真正的问题是双重的，首先是你需要解决的性能问题，今天是机器人造成了一个问题，但它向我表明，有一个性能问题需要解决。

其次，这是一个商业机会，可以把一些真正的垃圾转化为利润。所以我将保持整体woot风格并声明“我们检查机器人”。如果我们认为你是机器人，你就会得到一盒垃圾。”

机器人检查将在销售完成后的某个时间离线完成，使用机器人陷阱，IP号码，cookie，会话，浏览器字符串等。对你获得的购买者数据做一些认真的分析，以决定谁得到了废话。如果你决定发布垃圾，那么你就可以把一些正常的垃圾卖给别人。

一些想法:

Simple: don't name it "Random Crap." Change the name of the item every time so that the bots will have a harder time identifying it. They may still look for the $1.00 items, in which case I suggest occasionally selling $1 sticks of gum for a few minutes. The $5 shipping should make it worth your while. Harder: don't make the users do anything extra - make the users' computers do something extra. Write a JavaScript function that performs an intensive calculation taking a good amount of processing power - say, the ten-millionth prime number - and have the user's computer calculate that value and pass it back before you accept the order (perhaps even to create the "place order" URL). Change the function for every BoC so that bots can't pre-calculate and cache results (but so that you can). The calculation overhead might just slow down the bots enough to keep them off your backs - if nothing else, it would slow the hits on your servers so that they could breathe. You could also vary the depth of the calculation - ten-millionth prime versus hundred-millionth - at random so that the ordering process is no longer strictly first-come, first served, and to avoid penalizing customers with slower computers. E

如果您愿意强制使用javascript，您可以使用hashcash方案来要求(例如，对于每个请求)大约30秒的客户端计算。(当然，这在iPhone上可能是5分钟，在30台电脑组成的僵尸网络上可能是1秒:这是一个重大缺陷。)

您还可以通过使用(模糊的)javascript或(gag) flash生成页面来增加抓取的难度。

你也可以用不可见的(通过CSS和javascript)随机垃圾链接来寻找机器人。

你可以检测“类似机器人”的IP地址(通过速率和访问蜜罐链接)，并将它们重定向到一个特殊的服务器(例如，一个额外的CC验证，如“由visa验证”-或只是一个验证码。)

但实际上，这是一场军备竞赛。:)你很可能最终不得不升级到验证码之外。

这让我想到:为什么不从先到先得的模式转变为抽签模式呢?在这种模式下，机器人对真正的购物者没有那么大的优势。

好吧，我有几个问题，而不是一个答案，因为我没有技术经验，不知道它是否可以工作或有帮助。

目标如下: 1. 将道具卖给非脚本人。 2. 保持网站运行的速度不被机器人减慢。 3.不要让“正常”用户完成任何任务来证明他们是人类。

My questions are: -. Would a Flash application, or Java applet, or Silverlight or anything similar reduce the ease of screen scraping enough to decrease the impact of the bots? I'm curious if these are as wide open to external manipulation as typical javascript/html. While it is not standard for web development and may not be 'good' from an SEO point of view, it sounds like search visibility isn't your problem if you have millions of users. I believe that any of these could still offer a very good looking interface so your humans wouldn't be put off by the design.

-。你能把你所有的信息放在一张图片里吗?我也从未见过你所提到的woot部分，但我的建议是将人类需要知道的任何文本放在人类友好的图像中，而不是机器人友好的文本框中。

哦，还有一些在其他回答中提到的东西。不要错过你拥有的大好机会: 你有很多机器人的需求，那些拥有机器人的人真的会买，对吧?你还想要他们的钱吗?(如果不是，我就买了。)

这些拥有机器人的人有其他选择从你这里购买吗?把你的垃圾袋子拿出来。

为机器人建立一个woot子网站，让脚本写手获得很多乐趣，并为此付钱。卖给他们垃圾，让他们挑战其他编剧。这是一个完全不同的市场。

如果他们有另一种选择，可以赢得一些东西，并获得吹嘘的权利，他们可能不太倾向于殴打小老人。

如果这个答案已经提交，请原谅。有很多答案，要试着去阅读和理解所有的答案。

为什么不能每隔一段时间就改变一下购买API呢?难道这对人类用户来说不是完全透明的，并几乎杀死了大多数机器人购买者吗?

一种实现方法是更改用户在点击“I Want One”按钮后必须填写并提交的字段名称。你一年卖出多少次中行?不经常。因此，每次BOC发售时，编写、测试和准备使用不同的采购API不会是一个巨大的编程负担。

只要确保使用旧的和不正确的API的机器人不会使您的服务器瘫痪。每次也可以在不同的服务器上托管BOC购买API。这样，机器人就可以关闭一个服务器，而我们人类BOC购买者实际上并没有使用它。

如果我理解正确的话，你们最大的问题是屏幕抓取，而不是自动购买本身。

如果是这样，最有效的步骤是通过随机编码页面来击败屏幕抓取，这样它看起来是相同的(某种程度上)，但在代码级别上总是不同的。(使用十六进制编码，Java编码，图片，改变周边代码结构…)

这将迫使他们不断重写抓取代码，从而使他们自动购买你的“垃圾”变得更加昂贵。如果他们能做到的话。他们可能会继续访问你的网站一段时间，直到他们意识到他们不能从中获得任何东西，然后放弃它。

把机器人搞得一团糟的缺点是，它也会把搜索引擎爬虫搞得一团糟。

通过服务器上的iptables(如果是基于Linux的)或使用专用的“路由器”来限制每个IP地址的并发连接

只是一个旁注:在我看来，问题是，你的用户期望的行为非常类似于一个机器人(大波来，未经认证，点击每个按钮:))，所以验证码可能是唯一能够识别它的图灵测试:))。

You should have some record of the users who have purchased BOC most often, why not just ban those accounts or something. Sure legit users will be banned in this process but you are a business providing a product and if your are being abused by a group of users and such you have the right to refuse service to them. You have a lot of info on your users including paypal and bank accounts, you could ban those accounts forcing the bot users to get new accounts. Certainly I could come up with a script to buy BOC all the time or just download one from the net, but I have better morals than that. Never actually having successfully purchased BOC, I know the frustration of legit users who would like to receive a BOC in the hopes of getting a great deal. Perhaps instead of offering a BOC as an individual item every once and awhile, you could just give it to random users every day. When they receive an item they get a little note and and an additional item saying they also received a BOC. Then the only way someone could get a BOC is if they legitimately purchased something that only an actual human would have wanted. There would be nothing better than purchasing a coffee maker or something and also receiving a 42" tv or something in addition to your legitimate purchase. I think the majority of script kiddies would no longer be interested in your site if in order to get a BOC they would also have to commit to a purchase of more than 10 dollars.

前期事项:

我不会写剧本; 我还没读到其他的评论。

我今早在伍特的描述中无意中发现了这个。我认为来自woot网站的一个中等用户(两次手动购买boc)的一些评论可能会有所帮助。

Woot处于一个独特的位置，它既是一个商业网站，也是一个拥有忠实用户的目的地，我理解这种平衡的微妙之处。但就我个人而言，我觉得你对蹩脚验证码(“蹩脚验证码”——我怀疑我是不是第一个说这个笑话的人)对用户的“负面用户影响”的担忧是言过其实了。作为用户，我很乐意证明我是人。我相信Woot会让这个过程变得有趣，并将其整合到整体体验中。

Will this lead to the "arms race" posited? I dunno, but it can only help. If, say, key information to purchase is included in the product image or implied in the product description (in a different way each time), about the best a script could do would be to open a purchase page on detection of the C-word. Actually, I think this is fine: you are still required to be on-line and first-come-first-served still applies -- Wootalyzer and similar tools just increase awareness rather than automating purchase while I sleep or work.

祝你好运，继续努力。

JGM

把RSA密钥卖给每个用户怎么样:)嘿，如果他们能在《魔兽世界》中做到这一点，你们应该也能做到。

我希望我的答案是BoC;)

为什么不让首页只是一个图像映射图形(所有一张图片没有标签，标签等)?人类在几乎任何设备上都能轻松阅读和理解，但机器人却无法进行询问。从本质上讲，整个首页都是一个验证码。

你今天在灯上赚的钱足够支付思科的验证码程序了!!我们在购买演唱会门票和其他东西时都习惯了它们。这看起来很公平。今天的抽签方式让一些人感到不安，并提出了关于抽签或抽签的问题。我相信你在尝试之前已经调查过了，但这并不是一个有趣的购买boc的方式……这让所有的兴奋都消失了!

首先获得BOC或优秀的产品会吸引人们到Woot。如果没有理由在等待随机的BOC出现的同时购买大量你不需要的东西，销量就会下降。验证码可能是打败这些人的唯一方法，同时还能保持Woot的兴奋感。

我是上次第一个让它订购BOC的人之一，我的第一个订单被丢弃了，第二个订单通过了，但后来被从我的账户中扣除了。我很沮丧。我离开了Woot，没有像过去那样购买物品。我愿意今天再试一次，就这样。如果没有验证码，我估计以后也不会这么做了。

有许多网站试图成为Woot那样的网站。他们当然达不到你的水平。我发现自己阅读产品描述，不是因为我想要这个产品，而是为了好玩而查看。我不希望看到有人拿着一个更公平的项目进来，然后拿走你的大部分业务。

这只是我的个人观点。因为我是一名护士，所以我对机器人和电脑几乎一无所知。但我的建议是升级到更高的级别…带着机器人的人只需要和我们其他人站在一起，这就是它应该有的方式:) 罗莉

As for CAPTCHAing everyone, why not use the Google solution of only requiring CAPTCHAs from IPs you suspect as being bots, or even just users that hammer the site? I'm sure asking someone for a CAPTCHA when they purchase isn't so bad if they've been hammering the site anyway, its just about the same as staying up and hitting F5 repeatedly. That or maybe require a periodic CAPTCHA when hammering, say every hundred (maybe smaller?) or so refreshes, to stop alarm-bots from working. You need some sort of CAPTCHA to prevent botting, but you also need to account for the fact that your real users will act like bots.

作为Woot.com的长期用户(4年)和几袋垃圾的购买者，在我的车库中有许多其他的物品，似乎解决方案应该是Woot整体主题的一部分。

使用验证码，但要幽默。就像100万美元的促销一样，你也可以将自己当成一个人来做游戏。在过去，这使得中行的“售罄”推迟了一段合理的时间，而像我这样的人，则争先恐后地想出一个相当简单但幽默的谜题，输入优惠券代码。

此外，虽然人们不断抱怨服务器错误，但他们不会停止返回。在我看来，购买中行之所以令人兴奋，部分原因在于有无数人都想买。如果服务器抛出一个错误，或者一个奇怪的页面，这表明我是一群试图获得1500个产品中的一个的太多人中的一个。

如果你在构建谜题上投入了足够多的创造力，并且它足够新颖，它就会拖延机器人足够长的时间，给其他人一个机会。在“我想要一个”和购买页面之间放置一个临时页面，这需要一些独特的人类互动，你已经阻止了机器人，直到它们弄清楚需要发生什么。

• You haven't implemented a boring, and sometimes painfully difficult to read captcha • you've made the process more fun, • you've reduced the load on the actual secure purchase server • You'll train the users that they will need to "DO" something to get a BOC • You'll stopped the bots at the interim page, delaying their purchases until most people have at least had a chance to try and figure out the funny, but not terribly difficult puzzle. • Since being random is what a BOC is all about, a random, and changing puzzle/task would fit in simply with the whole pitch of a BOC.

随着试验的进行，临时页面背后的技术可能会变得更加先进，可以捕获用于购买页面的随机信息。自

自05年5月31日以来，我已经购买了7个BOC，没有机器人的帮助，也没有任何脚本，除了wootalyzer，我觉得这是一个可以接受的帮助。最好的一个，我没有得到，是Please Please Me BOC。B&D电池也很有趣，但我猜它并没有难倒机器人，只是让普通用户感到沮丧。

有时候，技术问题的最佳解决方案并不是更多的技术。

两种解决方案，一种高科技，一种低科技。

First the high-tech: The BOC offerings sell out in a seconds because bots get many of them in the first few milliseconds. So instead of trying to defeat the bots, sell them what they are scanning for: a bag of crap. Worthless crap, of course: bent paper clips and defiled photos of Rosie O'Donnell. Then have built-in random delays on the server for a few seconds at a time. As the sale continues, the actual value of the product sold will increase while the sell price does not. That way the first buyers (bots in the first few milliseconds) will get something worth much less than what they paid (brown onion cakes?), the next buyers (slower bots or faster humans) will get something unspectacular but worth the purchase price (bought on consignment?), and the last buyers (almost all humans) will get something worth more than the purchase price (break out champagne?). That flat-screen TV might be in the very last BOC purchased.

任何等待太久的人都会错过机会，但与此同时，任何购买太快的人也会吃亏。诀窍在于等待一段时间……但不要太多。这里面有一些运气，这是应该的。

低技术含量的解决方案是将中国银行的名称改为人类可以理解但机器人不能理解的名称。酒皮屎?装着臭味的麻袋?与各种商品相邻的拓扑平面?不要重复使用相同的名称，使用稍微不同的图片，并在产品描述中解释实际销售的产品。

对于你的特定问题(而不是一般问题)，一个潜在的解决方案是，如果用户想要看到“垃圾”，就要求他们登录。只向恰好登录的用户显示垃圾奖品。所有其他项目都可以对非登录用户保持可见，就像他们一直以来所做的那样。然后你的忠实用户就会优先考虑这些垃圾。

很明显，你必须通知你的用户这一点，也许会通知他们这是为了增加真正的用户发现垃圾的机会。

如果你的具体问题是机器人收集某种特定类型的物品，那么就采取限制性最小的替代方案，只防御这种特定的攻击。这个选项可以防止验证码和您所关心的可使用性问题。

如果机器人登录并开始发送垃圾邮件，您可以强制他们注销并锁定帐户。

如果他们只是为了得到一袋垃圾，他们会很快离开，你的页面不会受到大量的点击。忘掉那些高度技术性的解决方案吧。

2件事:

服务器层解决方案:mod_eveful(如果你使用apache)

http://www.zdziarski.com/projects/mod_evasive/

前端解决方案:反向验证码，或其他非侵入式验证码

http://www.ccs.uottawa.ca/webmaster/reverse-captcha.html

如果随机或加密表单名称和id，随机表单字段的顺序，并使表单标签成为随机验证码图像，会使脚本攻击变得更加困难:-D

让整个该死的页面验证码! 有点像芝麻街……其中八件不属于这里…

在屏幕上放9个项目，9个HTML表单，9个I WANT ONE按钮。 (9只是一天的数字……选择任何你想要的数字，使布局看起来仍然很好。也许12。也许自定义它一些加载浏览器的分辨率…)

给每个人搅和一下。 确保BOC必须被“看到”才能知道它是哪一个…当然，这意味着其他8个也必须“只看到”，知道他们不是购买的项目。 请确保您只使用疯狂的数字来引用页面源代码中幕后的所有内容。 好吧，BOT看到它的BOC时间…但要选择正确的HTML表单提交回去进行处理，这将是一个大胆的猜测。

可能没有一个神奇的银弹来照顾机器人，但这些建议的组合可能有助于阻止他们，并将他们减少到一个更易于管理的数量。 如果您需要对这些建议进行任何澄清，请告诉我:

Any images that depict the item should be either always the same image name (such as "current_item.jpg") or should be a random name that changes for each request. The server should know what the current item is and will deliver the appropriate image. This image should also have a random amount of padding to reduce bots comparing image sizes. (Possibly changing a watermark of some sort to deter more sophisticated bots). Remove the ALT text from these images. This text is usually redundant information that can be found elsewhere on the pages, or make them generic alt text (such as "Current item image would be here"). The description could change each time a Bag of Crap comes up. It could rotate (randomly) between a number of different names: "Random Crap", "BoC", "Crappy Crap", etc... Woot could also offer more items at the "Random Crap" price, or have the price be a random amount between $0.95 and $1.05 (only change price once for each time the Crap comes up, not for each user, for fairness) The Price, Description, and other areas that differentiate a BoC from other Woots could be images instead of text. These fields could also be Java (not javaScript) or Flash. While dependent on a third-party plug-in, it would make it more difficult for the bots to scrape your site in a useful manner. Using a combination of Images, Java, Flash, and maybe other technologies would be another way to make it more difficult for the bots. This would be a little more difficult to manage, as administrators would have to know many different platforms. There are other ways to obfuscate this information. Using a combination of client-side scripting (javascript, etc) and server-side obfuscation (random image names) would be the most likely way to do it without affecting the user experience. Adding some obfuscating Java and/or Flash, or similar would make it more difficult, while possibly minimally impacting some users. Combine some of these tactics with some that were mentioned above: if a page is reloaded more than x times per minute, then change the image name (if you had a static image name suggested above), or give them a two minute old cached page. There are some very sophisticated things you could do on the back end with user behavior tracking that might not take too much processing. You could off-load that work to a dedicated server to minimize the performance impact. Take some data from the request and send it to a dedicated server that can process that data. If it finds a suspected bot, based on its behavior, it can send a hook to another server (front end routing firewall, server, router, etc OR back-end web or content server) to add some additional security to these users. maybe add Java applets for these users, or require additional information from the user (do not pre-fill all fields in the order page, making a different field empty each time randomly, etc).

为什么你们不每次提供中行的时候都改一下名字和图片呢?看最新版本的BOC将成为追求乐趣的一部分。

创建一个简单的ip防火墙规则，如果检测到超过最大值，就将ip地址列入黑名单。每秒输入的请求数。

你这条路走得太艰难了。我可能会踢自己，因为我刚刚赢得了一个BOC从网站今天与机器人网站，但只是把随机废话文本验证码在网站主页上。机器人都在寻找文本“随机垃圾”。所以你基本上一开始就避免触发它们。任何用眼睛看的人都会发现上面写着“随机的废话”。

一个相当简单的解决方案是跟踪呈现表单和获得响应之间的时间差:机器人通常只有极短的毫秒响应时间，没有用户可以做到这一点;或者响应时间极长，长达数小时。

这里有一个django代码片段，以及更详细的描述:

验证码的替代方案(无需人工交互)

你知道，如果你使用pubsubhubbub发布你的RSS提要，人们就不必一遍又一遍地点击你的网页来查看Woot-off中的下一件事，他们只需要等待它出现在他们的谷歌Reader上。

我有一个解决方案(可能)没有列出(因为我还没有读完这里所有的……)

您可以通过浏览器的User Agent字符串跟踪唯一用户。从本质上讲，通过检查哪些信息是可用的“唯一”，你将能够获得足够的信息来区分不同的人(即使是在相同的IP地址上)。

看看EFF写的这篇文章 以及这个网站(也由EFF)，将“测试”你的独特只是基于你的用户代理从浏览器。

为了获得更好的唯一性，你可以在唯一性和ip地址的信息位之间进行比较，从而真正得到罪犯/机器人的可能性。

---

也从EFF签出这个pdf

使用多个订购按钮(四个或更多)怎么样?文件-命名它们为image1到image4，其中三个图像在视觉上是相同的(“不要点击这里”)，一个是“点击这里”。

对于每个销售，随机分配每个选项的图像#。让它们相当大，这样用户就不会不小心点错了。图像将是相同的文件大小。 一旦IP点击一个按钮，任何按钮，他们被带到适当的网页(订购过程，或“哎呀，你点击了错误的按钮”)，并被给予2分钟的超时重新访问服务器。

为此目的，我使用Cloudflare，因为它不会影响我的网站，但会自动阻止任何恶意用户的验证码，并为您提供更多的功能。

我可能没有完全理解这个问题，但我想到了这个主意。使用AJAX以固定的间隔绘制和更新动态内容，同时使用刷新故意减慢整个页面的加载速度。

例如，让整个页面在第一次访问时花整整15秒绘制，之后在设定的时间(比如5秒)后使用AJAX自动刷新动态内容。重载整个页面将是一个主要的缺点。页面可能会定期显示新信息(包括广告)，但是使用重载重绘整个页面会慢得多。

脚本kiddies可以找出AJAX查询并将其自动化，但是，对来自同一IP的请求进行速率限制也很容易。由于标准人类用户没有从浏览器发起这些请求的典型方法，因此很明显，从同一IP向AJAX URL发起的高速率请求将由某种形式的自动化系统发起。

我所读到的大多数解决方案最终都退化为一种反移动的情况，并不能抑制人们按照“公平竞争规则”进行游戏的积极性。

你有没有想过有目的的性能限制/影子禁止?如果你检测到来自一个IP的大量命中，你的CGI脚本是否故意延迟响应-或者让他们没有资格赢得该物品?

So If you say set a cookie on the system and you see it hitting you more than X per interval of time, you start delaying the responses more and more. If you see cookie X continue this behavior for some interval of time, you set the dreaded 'Can not win today come back tomorrow flag' and dont tell them - that way, even if they win, they still loose. If you have several parameters like this that would be easily/randomly tweekable, you could be changing the rules all the time in such a way that it would keep out the bots - but humans wouldnt even notice. Maybe you could have a login have a delay of X seconds - where the delay is depended on that IP addresses history of hits/logins :)

只是一两个想法