【问题标题】:PHP request spam prevention mechanismPHP请求垃圾邮件预防机制
【发布时间】:2012-02-13 18:12:37
【问题描述】:

我正在构建一个模型视图控制器 Web 应用程序,我想构建一个请求垃圾邮件机制,为什么?让我简单解释一下:

我们自己有一个 ajax 控制器,每个用户输入都是通过 ajax 接收的,在我的 Web 应用程序中没有直接执行 $_POST。

让我们想象一下 Ajax 控制器的一些操作,我们希望在其中设置垃圾邮件预防机制:

class AjaxController{
    private function setPrevention($interval){
        $latestActionRequest = $_SESSION['requests'][$this->action];

        if($prevention === null){
            $_SESSION['requests'][$this->action] = array('latest' => microtime(), 'interval' => $interval
        } else {
            // Calc difference here, and check if the interval was within range, else
            // the user was requesting the action method to quickly.
        }
    }

    public function _postComment(){
        $this->setPrevention(1000);

        // Apply validation, on the $_POST array, insert the to database.
    }
}

所以我们有一个发表评论的动作,我们只想让用户每秒发表评论,所以我们在会话中应用了一个非常基本的预防机制。

检查 setPrevention 方法中的注释。我有两个问题,我的第一个问题是,这种机制是个好主意吗?还是有其他更好的方法来构建它?

第二个问题是,如何检查最新的请求是否在区间范围内?和 microtime - microtime 我得到了以秒为单位的差异,但有些操作我想应用 500 毫秒的间隔。

到目前为止我得到了什么:

$_SESSION['requests']['postComment'] = array('latest' => microtime(true), 'interval' => 1000);
$difference = ($_SESSION['requests']['postComment'] - microtime(true));

此时 $difference 会返回 float(106.984388113) (等待 106 秒) 但是我们想要得到微时差,因为我们的间隔是 1000(这是 1 秒而不是 1000)

希望我的问题很清楚,感谢您的帮助。

【问题讨论】:

  • 修改了我对您的编辑的回答。

标签: php spam


【解决方案1】:

第一个答案应该有助于次秒计时。 microtime(true)

响应编辑:小数部分为亚秒计时。 .984 是您在精度方面寻找的部分。 .500 是您的 500 毫秒。我建议根据这个浮点值设置你的间隔。

您可以将差值乘以 1000,但如果您想调整到大于或小于毫秒的精度,那就更令人困惑了。我建议以后尽可能轻松地调整它。

关于防止垃圾邮件的机制有很多选择,但它们将取决于您的应用程序的具体需求。

我可以给你的最好建议是以某种方式抽象它,以便它可以获得比你现在可能需要的更多关于 AJAX 调用的信息,并构建一个现在可以工作的简单系统并记录有关请求的信息供审核。

垃圾邮件预防的最大问题是阻止合法用户并让他们烦恼。所以你能做的最好的事情就是让你自己或其他开发人员在未来更容易更换你的机制。您还需要拥有请求日志,以便能够确定垃圾邮件防护系统正在阻止哪些类型的请求。

【讨论】:

  • @MikeVercoelen 没问题,只是不要忘记这应该是您审查和修改的内容,以限制它对可用性的影响
【解决方案2】:

如果您使用microtime(true) 而不仅仅是microtime(),它将返回一个浮点数而不是一个字符串。使用浮点数,您将能够计算自原始请求以来经过的毫秒数。

确保使用microtime 作为开始时间和结束时间。

至于另一个问题,这绝对是您可以限制请求数量的一种方法。可能还有其他方法,而这个问题并不是 Stack Overflow 的真正设计目的。这是主观的。

【讨论】:

  • 我不同意第二点,对于这种特殊情况可能有最好的方法。回答这个具体案例的问题,然后可能在更普遍的案例中使用讨论是 SO 的核心。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-03-03
  • 2014-04-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-01-04
  • 2013-01-31
相关资源
最近更新 更多