ThinkPHP表单令牌报错_Token验证与CSRF防御机制-ThinkPHP-PHP中文网

token_error 表示令牌验证失败，是 csrf 防御正常生效的表现；根本原因是表单提交的 hash 值与 session 中存储的不一致，常见于刷新页面、重复提交、多表单冲突或 session 未正确初始化。

thinkphp表单令牌报错_token验证与csrf防御机制

表单提交提示“_TOKEN_ERROR_”就是令牌验证失败

这不是 CSRF 防御失效，恰恰是它在起作用——系统发现你提交的 __hash__ 值和 Session 里存的不一致，直接拦下了请求。常见现象包括：编辑页刷新后提交失败、AJAX 多次点击报错、前后端分离时模板未渲染令牌、或页面含多个表单但只手动加了一个 {__TOKEN__} 却没关其他表单的验证。

ThinkPHP 3.x 的 autoCheckToken() 方法会比对 $_SESSION['__hash__'][$key] 和表单中 __hash__ 字段值（格式为 key_value），任一缺失或不匹配即返回 false
默认开启 TOKEN_RESET => true，验证通过后立即销毁该 key，所以**同一令牌只能用一次**；若用户点了两次“保存”，第二次必然失败
别指望清缓存（Runtime/Cache）能解决——令牌存在 Session 里，要清的是 $_SESSION 或重启会话

为什么 `C('TOKEN_ON', false)` 关了还报错？

因为关闭时机太晚：模板已经渲染完，{__TOKEN__} 已生成并写入 HTML，但控制器里才关配置，导致服务端验证逻辑仍执行，而 Session 中无对应令牌，自然判为非法。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

正确做法是在控制器 Action 开头就关，且确保早于 $model->create() 或 $this->display()：
C('TOKEN_ON', false);
$this->display(); // 必须在 display 前关，否则模板已注入 token
更稳妥的是在模板顶部加 {__NOTOKEN__} ——它会让 TokenBuildBehavior 直接跳过当前表单，不生成隐藏域也不校验
注意：{__NOTOKEN__} 必须放在 <form></form> 标签内、且**紧邻开头**（如 <form>{__NOTOKEN__}</form>），放错位置会被忽略

多表单页面怎么避免互相干扰？

ThinkPHP 默认对页面所有 <form></form> 都尝试注入 {__TOKEN__}，但 Session 只存一份令牌数据，多个表单共用一个 __hash__ 字段就会撞车。

手动控制：删掉自动注入，在每个需要验证的表单内精准添加 {__TOKEN__}，其余表单加 {__NOTOKEN__}
确认 TOKEN_NAME 没被多个模块意外覆盖（比如某插件重设了 C('TOKEN_NAME', 'token')，而模板仍写 {__TOKEN__}）
如果用了 AJAX 提交，别依赖模板生成的 token——改用接口返回新 token，前端动态写入，再提交（需后端配合 buildToken() 或手动构造）
检查中间件：TP5/6 必须启用 \think\middleware\SessionInit::class，否则 $_SESSION 为空，令牌根本存不住

Token 验证失败却不报错？那可能是 Session 没启起来

最隐蔽的坑：令牌验证逻辑本身执行了，但因 Session 未初始化，$_SESSION 始终为空数组，isset($_SESSION['__hash__']) 恒为 false，导致 autoCheckToken() 直接返回 true（见源码中 if(C('TOKEN_ON')){...} return true; 分支）——表面成功，实则防御形同虚设。