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

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

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

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

为了保持服务器端的简单性，你可以说在任何时候，只有一个cookie会让你看到糟糕的销售情况;还有一些其他的cookie被标记为“在最近2秒内生成的”，这些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。

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

如果您在一两个小时内释放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用户之前获得机会。

——罗伯特。

如何像SO那样实现captcha呢?

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

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

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

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

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

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

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

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

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

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

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

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

如果我们可以接受这样一个前提，即我们可以在一个全新的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，可以用来限制他的活动。

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

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

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

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

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