看起来我们将为Stack Overflow添加CAPTCHA支持。这对于防止机器人、垃圾邮件发送者和其他恶意脚本活动是必要的。我们只希望人类在这里发布或编辑东西!

我们将使用JavaScript (jQuery)验证码作为第一道防线:

http://docs.jquery.com/Tutorials:Safer_Contact_Forms_Without_CAPTCHAs

这种方法的优点是,对于大多数人来说,CAPTCHA永远不会可见!

然而,对于禁用JavaScript的人,我们仍然需要一个备用方案,这就是棘手的地方。

我为ASP编写了一个传统的CAPTCHA控件。NET,我们可以重复使用。

但是,我更倾向于使用一些文本化的东西,以避免为每个请求在服务器上创建所有这些图像的开销。

我见过这样的事情…

ASCII文本验证码:\/\/(_)\/\/ 数学难题:7减3乘以2等于多少? 小问题:癞蛤蟆和冰棍,哪个更好吃?

也许我只是在风车这里倾斜,但我希望有一个更少的资源密集型,非图像为基础的<noscript>兼容的验证码,如果可能的话。

想法吗?


当前回答

令人困惑的一件事是谷歌,显然是世界上拥有最多CS博士的公司,他们的验证码被破坏了,而且似乎没有采取任何措施。

其他回答

我真的很喜欢这个网站上使用的验证码方法:http://www.thatwebguyblog.com/post/the_forgotten_timesaver_photoshop_droplets#commenting_as

我认为一个定制的验证码是你最好的选择。这种方法需要一个专门针对机器人/脚本来破解它。这种努力因素应该会减少尝试的次数。人类毕竟是懒惰的

一种选择是带外通信;服务器可以向用户发送即时消息(或短信?),然后他/她必须在验证码字段中输入该消息。

这给用户带来了一个“非此即彼”的要求——要么你必须启用JavaScript,要么你必须登录到你所选择的IM服务。虽然它可能不像上面的一些其他解决方案那么灵活,但它适用于绝大多数用户。

那些拥有编辑权限的人,可以随意添加优点/缺点,而不是单独提交回复。

优点:

可访问:许多IM客户端支持读取传入消息。一些基于web的客户端将与屏幕阅读器一起工作。

缺点:

javascript禁用的用户现在依赖于OpenID之上的另一个服务的正常运行时间。 机器人将导致额外的服务器资源使用(发送带外通信),除非实现额外的保护

当我看到一个关于人类计算的视频(该视频是关于如何使用人类通过游戏来标记图像)时,我有了一个想法来构建一个验证码系统。人们可以使用这样的系统来标记图像(可能用于其他目的),然后使用关于标记的统计信息来选择适合验证码使用的图像。

假设有一张图片,90%的人都给它贴上了“猫”或“摩天大楼”的标签。然后可以呈现图像,要求图像最明显的特征,这将是图像的主导标签。

这可能超出了SO的范围,但有人可能会发现这是一个有趣的想法:)

请打电话给xxxxx,让我们谈谈你那里的天气。

但是,现在的发展太快了,利润导向也太大了,对我们选择的服务提供商来说,即使是一个电话也太贵了(时间很宝贵)。

我们接受了大部分时间与机器交谈。

悲伤的时光...