ThinkPHP模型只读字段_保护数据签名防止篡改【技巧】

ThinkPHP模型只读字段：一个被广泛误解的“安全”功能

在ThinkPHP开发中，$readonly属性常被误认为是防止API数据篡改的“金钟罩”。但真相是：它完全不是干这个的。 这个模型层的字段过滤机制，只在特定的模型写入操作中生效，对于防范恶意请求、保护接口完整性，可以说基本“不设防”。真正的安全防线，必须构筑在别处。

为什么 $readonly 对 API 篡改毫无作用

首先得明确一点：$readonly是数据组装阶段的过滤机制，而非安全边界。它的生效时机，是在数据即将通过模型写入数据库之前。而一个恶意的API请求，在抵达这个环节之前，早已穿过了Nginx、路由、中间件等层层关卡，甚至可能已经触发了业务逻辑。

来看几个典型的失效场景：

• 绕过模型操作：假设客户端提交了{“id”:123,“status”:“99”,“sign”:“xxx”}，意图修改订单状态。即便你在模型里定义了$readonly = [‘status’]，但如果开发者直接使用Db::name(‘order’)->where(‘id’, 123)->update([‘status’=>99])，$readonly根本无从拦截。
• 强制赋值参数：即使走了模型保存，使用$model->data($data, true)->sa ve()时，那个true参数意味着强制赋值，会直接跳过$readonly的检查。
• 字段名大小写问题：数据库字段是pay_status，而$readonly里写成了payStatus？框架无法识别这种不一致，保护自然就失效了。

所以说，把防篡改的希望寄托在$readonly上，无异于在城门失火后，才去检查内院的门闩。

真正防篡改必须靠签名验证 + 中间件拦截

那么，正确的防线应该设在哪里？答案是：签名验证，并且必须放在所有业务逻辑之前执行——通常就是在中间件里。ThinkPHP控制器内部的校验来得太晚了，等请求进到控制器方法，数据可能已经入库，甚至触发了后续不可逆的操作。

构建一个可靠的签名验证机制，有几个关键点不容忽视：

• 验签必须使用原始输入：处理JSON请求体，要用$this->request->rawInput()；如果是表单数据，则分别获取$this->request->get()和$this->request->post()。切忌使用param()方法，因为它会自动进行urldecode和类型转换，可能破坏原始数据的完整性。
• 规范签名原文的拼接：参数需要先用ksort()排序，每个value都要经过rawurlencode()处理，剔除签名本身（如sign字段），最后再追加上密钥。这套流程必须严格，一个环节出错，整个验证就可能被绕过。
• 防御重放攻击：客户端必须生成并传入timestamp（时间戳），服务端校验其是否在合理时间窗口内（比如±300秒）。同时，需要客户端传入随机字符串nonce，并在服务端（如用Redis）缓存一段时间（例如600秒）用于去重，否则攻击者截获一次合法请求后，可以反复重放。

$readonly 和签名该谁管什么字段

厘清职责是关键。$readonly和签名验证是两套完全不同的机制，混为一谈只会埋下隐患。

• $readonly的职责：管理“业务逻辑中不应被随意覆盖的字段”。它适合保护那些由系统生成或决定的字段，例如：
  • 记录创建时间的create_time。
  • 用于软删除的delete_time。
  • 标识数据来源的source。
  • 状态机的关键字段，如pay_status（防止用户直接提交status=2将“待支付”改为“已支付”）。
• 签名验证的职责：校验“整个请求是否来自合法的客户端，且数据在传输过程中未被篡改”。它关注的是请求体的完整性。如果发现日志里pay_status被非法修改了，问题根源往往不是$readonly失效，而是签名验证没能拦住非法请求，或者有人绕过了模型直接操作了数据库。
• 敏感字段的双重保护：对于amount（金额）、user_id（用户ID）这类极度敏感的字段，仅靠$readonly是不够的。更稳妥的做法是，在签名验证通过后、模型写入前，通过专用的业务方法（例如$order->confirmPayment()）来封装状态流转逻辑，并在方法内部校验当前状态是否允许进行此类变更。

立即学习“PHP免费学习笔记（深入）”；

最容易被忽略的致命细节

很多开发者以为配置了$readonly就万事大吉，直到线上出了问题才追悔莫及。一些常见的“坑”与签名无关，纯粹是模型配置和使用方式的问题：

• 自动更新时间戳失效：如果把update_time字段加入$readonly列表，那么模型的自动更新时间戳功能就会失效。除非你在模型的beforeUpdate事件钩子里手动为其赋值。
• 主键自增混乱：绝对不要将主键id加入$readonly。ThinkPHP在新增数据时，依赖这个字段来生成自增ID或UUID，将其设为只读会导致插入失败或主键为空。
• 继承模型的配置合并：如果子类模型继承了父类，父类中定义的$readonly属性不会自动合并到子类。必须在子类中显式地合并数组：protected $readonly = array_merge(parent::$readonly, [‘xxx’])。

总而言之，$readonly是一个有用的模型属性保护工具，但它绝非安全卫士。构建坚实的API防篡改体系，必须依赖前置的签名验证与中间件拦截，两者职责分明，不可替代。而$readonly，则应该回归其本职工作——在模型层守护那些不应被业务逻辑意外修改的字段。理解并区分这三者的关系，才是写出健壮、安全代码的关键。