Rails - 选择验证码插件[关闭]

Question

Rails 中有很多验证码插件，也有很多类型的防止垃圾邮件和洪水的解决方案。所以这不仅仅是 Rails 的问题。

让我们看看我们有哪些类型的插件：

1.经典图像验证码 (zendesk 的验证码, ，简单_验证码，验证_验证码， 温顿的验证码, ，拉普查）。

积极的：

• 可以有效地防止自动解密（不确定 Simple_captcha，但似乎 zendesk 和 winton 的验证码都没有实现这一点，因为它们使用预先生成的图像（而不是按需），因此我们可能的垃圾邮件机器人可以是从这些图像中学到的）。

消极的：

• 需要数据库表（至少是简单验证码。还不错，但是使用后他们会清洗吗？）。
• 需要 RMagick 或类似的（对我来说不是那么实际，因为我已经在我的网站上有了它）。
• 手动解密失败（据我所知图像价格为 2/1000 美元）。
• 令用户烦恼并会降低转化率。

2.验证码 （验证码、机架验证码）。

积极的：

• 可以有效防止自动解密。
• 不需要 Rmagick 和 DB 表。

消极的：

• 对第 3 方站点进行 api 调用。
• 手动解密失败。
• 甚至比之前还要烦人。

3.蜜罐 （负验证码、Trap_door、反向验证码、蜜罐验证码、Bouncy_bots、 隐形验证码).

积极的：

• 用户不知道验证码的存在。
• 不需要 Rmagick 和 DB 表。

消极的：

• 自动解密可能会失败（有没有可以识别此插件的机器人？）。
• 手动解密失败。

4.基于文本的 （Humanizer、Brain_buster、问题）。

积极的：

• 不需要 Rmagick 和 DB 表（Brain_buster 除外）。

消极的：

• 自动解密可能会失败。
• 手动解密失败。
• 有点烦人（可以本地化）。

5.其他 （充当斯努克）

积极的：

• 用户不知道验证码的存在。
• 不需要 Rmagick 和 DB 表。

消极的：

不知道有没有，因为很不寻常。但我认为在洪水泛滥的情况下可能会出现问题，因为有时可能需要帖子的审核。

6.类似 Akismet 的解决方案 （不知道他们的效率）。

积极的：

• 用户不知道验证码的存在。
• 不需要 Rmagick 和 DB 表。

消极的：

• 对第 3 方站点进行 api 调用。
• 将用户的详细信息传递给第三方网站（非常非常糟糕）。

我还应该谈谈我的网站。用户只有在 ajax 请求之后（例如将东西放入购物车之后）才能看到受保护的表单。现代机器人是否有能力执行 ajax 请求和存储 cookie？

Answer 1

洪水泛滥是与垃圾邮件不同的问题。您绝对应该在应用程序中构建有关速率限制的逻辑，您可以使用验证来检查用户是否在过去 15 分钟内下达了超过 2 个订单。

关于验证码，您选择的任何插件很可能都会很棒。我不认为必须安装 RMagick 是积极的还是消极的，它确实并不难开始工作。如果是我选择，我的第一反应是使用验证码，这是其中最不烦人的。

垃圾邮件是另一个问题，它通常是由可以绕过您的验证码的人类用户输入的。Akismet 非常适合捕获垃圾邮件，一定要看看它，您可以将它与 recapcha 之类的东西结合使用。

最后，现代机器人非常复杂。比我们任何人想象的都要复杂得多。他们可以完全自动化浏览器，使用 OCR 读取验证码文本并生成垃圾内容，甚至可以绕过最复杂的过滤器。也就是说，这并不是要“阻止所有垃圾邮件/机器人”，而是要将进入门槛设置得足够高，以至于对于临时用户来说不值得。

Answer 2

对现有插件的良好分析。

现代机器人非常复杂，而且它们的开发人员的薪水很高，因此它们总是试图绕过最新的防御措施。出于这个原因，我认为坚持使用积极维护和开发的选项是件好事，比如 ReCaptcha。我还认为用户了解界面，并且知道您正在采取措施保护他们的数据，因此感到安全。

我必须筛选项目的所有 Rails 验证码选项，并编写一个示例应用程序供我的客户测试和试用。simple-captcha-demo.heroku.com

它们都非常易于使用和设置，我喜欢使用 heroku 作为测试平台来快速设置某些东西，并让客户进行测试。我还在我的博客上写了一些我的经验和陷阱 RailsPerformance.com

可能会有新插件，看看流行趋势总是好的www.ruby-toolbox.com