想象一下，在一个活动中，拥有产品包中唯一获胜代码的访问者只需输入代码即可立即获胜。客户在验证获胜代码后想要电子邮件等。这并不常见，但与在检查是否赢得i.m.h.o.之前要求提供电子邮件和个人数据相比，这更令人同情
因此，访问者的流量将是：
[ ENTER CODE ]
!win -> [ TOO BAD ]
win -> [ CONGRATULATIONS ] -> [ ENTER PERSONAL DATA ]
这种情况意味着暴力机器人可以尝试代码，直到响应不同，这意味着一个获胜的代码。你会使用/重新建立一个captcha吗？
你将如何抵御洪水？攻击者可以很容易地为每个请求伪造IP/UserAgent。
在这种流动中，有可能保护这样一种机制吗？
一般问题，一般答案。。。
最好让代码足够长，这样就不可行了。
考虑一下威胁模型：为什么有人会这么做？奖金那么高吗？
攻击者欺骗IP是没有意义的，因为他们永远不会看到响应，而且他们不能用TLS&HTTP(它们可以隐藏在代理后面，但这不是欺骗(。只要代理/IP的数量远小于可能的代码数量，就不应该有IP限制的问题。
你可能会让请求变得昂贵——使用挑战-响应系统让客户端进行大量的哈希迭代来对请求进行评级(请参阅hashcash(。如果需要1秒的时间，这将大大限制潜在的请求率，但不会过度惩罚真实用户。