处理 Rails 中的用户滥用行为
我一直在开发一个可能容易受到用户滥用的网络应用程序，尤其是垃圾评论/帐户。我知道 RECAPTCHA 会处理假用户的机器人，但对于那些创建帐户并以某种方式将垃圾评论置于自动驾驶仪上的用户来说，它不会做任何事情（就像我在 Twitter 上无数次看到的那样） 。
我想到的解决方案是使任何用户能够标记另一个用户，然后在只能由管理员访问的用户索引操作上显示标记的用户列表（布尔属性）。然后，已被标记的用户可以成为禁止（另一个布尔属性）或取消标记的候选者。被禁止的用户仍然可以访问该网站，但权限会大大减少。由于某些原因，我不想完全删除用户。
然而，当我想到这一点时，我意识到，浏览标记用户列表来决定哪些用户应该被禁止或取消标记，对于管理员来说可能非常耗时。除了雇用某人来对用户进行举报/禁止之外，是否有更自动化和更优雅的方法来解决此问题？
I've been working on a web app that could be prone to user abuse, especially spam comments/accounts. I know that RECAPTCHA will take care of bots as far as fake users are concerned, but it won't do anything for those users who create an account and somehow put their spam comments on autopilot (like I've seen on twitter countless times).
The solution that I've thought up is to enable any user to flag another user and then have a list of flagged users (boolean attribute) come up on a users index action only accessible by the admin. Then the users that have been flagged can become candidates for banning(another boolean attribute) or unflagging. Banned users will still be able to access the site but will have greatly reduced privileges. For certain reasons, I don't want to delete users entirely.
However, when I thought of it, I realized that going through a list of flagged users to decide which ones should be banned or unflagged could be potentially very time consuming for an admin. Short of hiring someone to do the unflagging/banning of users, is there a more automated and elegant way to go about this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果一些老练的垃圾邮件发送者认为奖励足够高，他们会很乐意花时间破解您的验证码。您还应该考虑查看垃圾邮件服务器，例如 akismet，它有一个很棒的 Rails 插件 (https://github.com/a href="https://github.com/joshfrench/rakismet" rel="nofollow noreferrer">https://github.com/akismet/ com/joshfrench/rakismet）。
还有其他替代方案，例如 defensio (https://github.com/thewebfellas/defensio-ruby）以及我曾经发现的一个宝石，它在检测常见博客垃圾邮件方面非常有效，但我再也找不到它了。
Some sophisticated spammers are happy to spend their time breaking your captcha if they feel that the reward is high enough. You should also consider looking at a spam server such as akismet for which there's a great rails plugin (https://github.com/joshfrench/rakismet).
There are other alternatives such as defensio (https://github.com/thewebfellas/defensio-ruby) as well as a gem that I found once which worked pretty well at detecting common blog spam, but I can't for the life of me find it any more.
我将创建一个名为“滥用”的表，其中包含报告的用户和提交报告的用户。我建议使用计数器缓存列，例如“abuse_count”，而不是标记的布尔字段。当此列达到预定义值时，您可以自动“禁止”用户。
I would create a table named abuses, containing both the reported user and the one that filed the report. Instead of the flagged boolean field, I suggest having a counter cache column such as "abuse_count". When this column reaches a predefined value, you could automatically "ban" the users.
在“Web 2.0”之前，网站由管理员管理。现在的目标是让社区自我调节。 StackOverflow 本身就是一个很棒的案例研究。 信誉系统使用户能够在证明自己值得信赖时承担更多“管理”任务。如果您允许用户互相标记，那么您就已经走上了这条道路。至于系统的细节（谁可以标记、取消标记和禁止），我建议您应该查看各种成功的在线社区（例如 StackOverflow），看看它们是如何工作的以及它们有多成功。最终可能需要一些尝试和错误，因为所有社区都不同。
如果您想编写一些代码，您可以创建一个脚本来查找垃圾邮件发送者的典型使用模式（例如，在多个页面上发布相同的评论），尽管我认为目标应该是发展一个为您执行此操作的社区。这可能更多的是关于计划而不是编程。
Before "Web 2.0", web sites were moderated by administrators. Now, the goal is to get communities to moderate themselves. StackOverflow itself is a fantastic case study. The reputation system enables users to take on more "administrative" tasks as they prove themselves trustworthy. If you're allowing users to flag each other, you're already on this path. As for the details of the system (who can flag, unflag, and ban), I'd say you should look at various successful online communities (like StackOverflow) to see how they work, and how successful they are. In the end it will probably take some trial and error, since all communities differ.
If you want to write some code, you might create a script that looks for usage patterns typical of spammers (eg, same comment posted on multiple pages), though I think the goal should be to grow a community that does this for you. This may be more about planning than programming.