2026/09/14 博客更新日志

作者：周明辉

•

发布时间：2026年9月14日周一

• 归档在：博客更新日志

DeepSeek V4.1 Flash 出了，我就趁机试了一下。

用deepseek进行了以下网站更新：

重构前后端部分js文件代码，解耦+提取公共函数。
优化界面加载，完善后端管理界面的许多缺陷。
堵住了一个XSS漏洞。
修复了一个管理员后台的CSFR令牌相关的**Joke**。大致就是前后端发请求时，需要CSFR令牌，但是之前的v4模型写代码的时候，完全没有放CSFR，之所以一直没有炸雷是因为退出登录按钮，有CSFR令牌.......

Joke:

F-02 🟡 CSRF token 的取值路径是隐性的

现象

resources/js/ui-ajax.js:13-21：

function uiCsrfToken() {
  const meta = document.querySelector('meta[name="csrf-token"]');
  if (meta && meta.content) return meta.content;
  const input = document.querySelector('input[name="_token"]');
  if (input && input.value) return input.value;
  const m = document.cookie.match(/(?:^|;\s*)XSRF-TOKEN=([^;]*)/);
  return m ? decodeURIComponent(m[1]) : "";
}

三个 admin 页面的 <head> 里都没有 meta[name="csrf-token"]：

页面	meta	页面内 `input[name="_token"]`
`/admin`	无	有（`md-upload-form` 里的 `@csrf`，`admin/index.blade.php`）
`/admin/posts`	无	没有（页面自有表单一个都没有）
`/admin/users`	无	没有

那么 posts / users 页面的 token 是从哪来的？来自 resources/views/common/header.blade.php:38 附近 —— 已登录态下右上角"点此登出"表单里的 @csrf 生成的隐藏 _token。也就是说，这两个管理页的所有写操作（删除/恢复/彻底删除/切换管理员/上传内容）目前依赖一个跟管理功能毫无关系的登出按钮。

同时第三段兜底 document.cookie 的写法本身也有问题：Laravel 的 XSRF-TOKEN cookie 是加密值，只能作为 X-XSRF-TOKEN 请求头发送（服务端会解密），直接塞进 X-CSRF-TOKEN 会因为拿到密文而校验失败。

影响

某个"整理 header"的改动（把登出按钮换成 fetch、加 @guest 更严格的条件、把登出挪进下拉菜单）就会静默让 posts / users 页面全部写操作返回 419，而 /admin 因为有自己的表单仍然正常 —— 这类"只坏一半"的问题最难排查。
三个页面没有 419 的友好提示（见 F-15），用户只会看到"请求失败（HTTP 419）"。

好像就没有其他的点了。

TODO LIST (全新的)

重构后端上传文章逻辑。

支持文章加载图片。

支持邮件提示。