Yii框架REST签名与参数校验教程

本文深入解析了Yii2框架中RESTful接口的安全加固核心实践，重点揭示了签名验证与参数校验必须手动实现的关键事实：签名需在beforeAction中统一提取原始参数、字典序拼接并HMAC校验，严禁依赖自动转换方法；参数校验绝不能跳过原始值获取直接类型强转或拼接SQL，而应通过验证器或filter_var严格约束后再进入业务逻辑；同时厘清了不同Content-Type下正确读取请求数据的方法差异，并提供了轻量可复用的验证组织方案，帮助开发者避开越权、SQL注入、类型混淆等高频安全陷阱。

Yii RESTful 接口本身不提供签名机制，sign 必须手动实现；参数校验也**不是自动发生的**，$request->get() 和 $request->post() 返回的永远是原始字符串，不校验、不转类型、不过滤。

怎么在 Yii2 RESTful 接口中加 sign 签名验证

签名通常用于防止请求被篡改或重放，常见于开放 API 场景。Yii 没内置支持，需在控制器行为或基类中统一拦截处理。

• 签名逻辑一般放在 behaviors() 的 AuthMethod 子类里（比如自定义 SignAuth），而不是写在每个 action 里
• 典型流程：提取所有非 sign 参数 → 按 key 字典序排序 → 拼接成字符串 → 与约定密钥一起 md5() 或 hash_hmac('sha256', ...)
• 注意：必须排除 sign 字段本身，且要统一处理空值、布尔值、嵌套数组——实际中建议只对 flat query string 校验，避免 JSON body 解析后结构差异引发签名不一致
• 客户端传 sign=xxx 时，服务端用 $request->get() 或 $request->getBody() 解出原始参数后立即计算比对，失败直接 throw new BadRequestHttpException('Invalid sign')

示例片段（放在控制器基类中）：

public function beforeAction($action)
{
    $params = $this->getRequestParams();
    $clientSign = $params['sign'] ?? '';
    unset($params['sign']);
    ksort($params);
    $expected = hash_hmac('sha256', http_build_query($params), 'your_shared_secret');
    if (!hash_equals($expected, $clientSign)) {
        throw new BadRequestHttpException('Invalid sign');
    }
    return parent::beforeAction($action);
}

protected function getRequestParams()
{
    $contentType = \Yii::$app->request->getContentType();
    if ($contentType === 'application/json') {
        return \Yii::$app->request->getBodyParams() ?: Json::decode(\Yii::$app->request->getRawBody());
    }
    return \Yii::$app->request->get() + \Yii::$app->request->post();
}

为什么不能直接用 $request->get('xxx') 做校验

因为 $request->get('id') 返回的是字符串 "1abc"，不是整数；$request->get('email') 可能是 "@test.com"；它不做任何清洗或类型约束。

• 常见错误：写 $id = (int)$request->get('id'); —— 输入 "0x123" 或 "1e2" 会被转成 0 或 100，但数据库查询仍可能执行成功，造成越权或逻辑错乱
• 更糟的是：$request->get('order') 直接拼进 SQL ORDER BY $order，导致 SQL 注入
• 正确路径是：先取原始值 → 再走验证层（模型 or 单独 validator）→ 验证通过后才赋值给业务变量
• 轻量场景可用 filter_var($value, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]])，但注意它不处理 null 或空字符串，得额外判 !empty()

RESTful 控制器里怎么组织参数验证才不啰嗦

别为每个 action 新建一个 Model 类，也别反复 new Validator。推荐复用 ParamsValidateService 这类轻量验证封装，规则动态传入。

• 规则格式保持和 Model::rules() 一致，例如 [['page', 'size'], 'required']、[['id'], 'integer', 'min' => 1]
• 关键点：验证前必须把参数“扁平化”——JSON body 要先 Json::decode()，否则 validate() 会跳过嵌套字段
• 错误收集要用 $model->getErrorSummary(true)，它返回一维数组，适合直接塞进 apiError() 响应体
• 注意兼容性：ParamsValidateModel 继承 ActiveRecord 是为了复用验证框架，但它不连 DB，所以必须重写 attributes() 返回动态字段列表，否则 load() 会静默丢弃未声明属性

容易被忽略的边界：Content-Type 决定你该读哪个方法

前端发 application/json，你还调 $request->post('xxx')，结果一定是 null。这不是 bug，是设计如此。

• $request->post() 只读 application/x-www-form-urlencoded 和 multipart/form-data 的 body
• $request->get() 只读 URL query string，不管 content-type
• JSON 请求必须用 $request->getRawBody() + 手动 Json::decode()，且要捕获 JSON_ERROR_* 异常
• 混合场景（如表单带文件上传又含 JSON 字段）极难处理，建议拆成两个接口，或统一要求前端用 form-data 传 JSON 字符串再二次解析

文中关于Yii框架的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Yii框架REST签名与参数校验教程》文章吧，也可关注golang学习网公众号了解相关技术文章。