yii2 restful接口需手动实现sign签名验证与参数校验，签名应在beforeaction中统一处理，参数须原始获取后按字典序拼接并hmac校验；参数校验不可依赖$request->get()等自动转换，必须先取原始值再通过验证器或filter_var严格校验。
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') 可能是 "<script>alert(1)</script>@test.com"；它不做任何清洗或类型约束。
- 常见错误：写
$id = (int)$request->get('id');—— 输入"0x123"或"1e2"会被转成 0 或 100，但数据库查询仍可能执行成功，造成越权或逻辑错乱 - 更糟的是：
$request->get('order')直接拼进 SQLORDER 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 字符串再二次解析
