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

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

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

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

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

目前，销售垃圾促销袋部分的技术方面被处理为正常的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.

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

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

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.

以下是我的看法。攻击机器人所有者的投资回报率，这样他们就会做你想让他们做的合法事情，而不是欺骗。让我们从他们的角度来看。他们的资产是什么?显然，无数的一次性机器、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

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

我将要描述的方法有两个要求。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.