前后端分离网站，如何安全接入 WordPress Application Passwords

今天这次维护不是简单修一个报错，而是把一个更长期会影响后台使用、用户授权和内容发布的问题一起梳理掉：在前后端分离的网站里，用户如果要使用 WordPress Application Passwords，凭据到底应该放在哪里，谁来发起授权，谁来调用 API。

先修复后台，再处理授权链路

一开始的问题出现在 WordPress 后台入口：WordPress 后台抛出 Call to undefined function nocache_headers()。排查后确认不是 WordPress 核心函数丢失，而是站点配置文件异常，导致后台加载链路没有正确进入 WordPress 运行环境。修复配置后，后台登录、REST API 和基础管理链路都恢复正常。

后台恢复以后，真正需要补上的，是前后端分离场景下的授权方案。用户访问的是 www.shmlang.com，WordPress API 在 api.shmlang.com，如果直接把 Application Password 交给浏览器保存，后续任何脚本、插件或浏览器环境风险都会扩大。

最终采用的方案：前端发起，服务端保存，服务端代理

这次选择的是 B + C 方案：前端负责发起 WordPress 授权，www 服务端负责接收回调、加密保存凭据，并代理后续 REST API 调用。

• 用户在设置页点击“连接 WordPress”。
• 前端跳转到 WordPress Application Password 授权页。
• 用户在 WordPress 后台确认授权。
• WordPress 回调 www.shmlang.com/api/wp-application/callback。
• www 服务端校验一次性 state，使用 AES-256-GCM 加密凭据。
• 浏览器只拿到 HttpOnly Cookie，前端 JS 不能读取 Application Password。
• 后续调用统一走 /api/wp-application/proxy/...，由服务端加 Basic Auth 访问 WordPress REST API。

为什么不是让前端直接保存密码

Application Password 本质上就是一个可调用 WordPress API 的长期凭据。把它放在 localStorage、页面状态或普通接口响应里，都意味着浏览器端可以直接读到。对普通用户来说，这个体验看似简单，但对一个要长期维护 SEO、内容发布和后台能力的网站来说，风险边界太大。

现在的处理方式把浏览器变成“授权入口”，而不是“凭据仓库”。前端只知道是否已连接、授权账号是谁、授权站点是哪一个；真正的密码永远只在服务端解密和使用。

这次落地了哪些能力

• 授权入口：新增 /api/wp-application/start，自动生成 state 并跳转到 WordPress 授权页。
• 安全回调：新增 /api/wp-application/callback，校验 state、校验 API 站点、加密保存凭据。
• 连接状态：新增 /api/wp-application/status，只返回公开状态，不返回密码。
• 断开连接：新增 /api/wp-application/disconnect，清除本地加密凭据。
• 代理访问：新增 /api/wp-application/proxy/[...path]，让后续发布笔记、更新内容、读取后台数据都可以由服务端代发请求。
• 设置页 UI：在创作者设置页增加 WordPress API 授权卡片，让用户能看到连接状态并发起授权。

异常场景怎么处理

• 用户取消授权：回到设置页并显示取消提示，不保存任何凭据。
• 回调缺少密码或账号：拒绝保存，提示重新授权。
• state 校验失败：视为异常回调，拒绝保存。
• 回调站点不匹配：拒绝保存，防止把凭据绑定到错误站点。
• 服务端没有配置加密密钥：保存失败，提示检查 WP_APPLICATION_CREDENTIAL_SECRET。
• 代理接口没有授权 Cookie：返回标准 401 JSON 错误。

后续可以继续升级的地方

当前版本使用 HttpOnly 加密 Cookie，适合快速落地和单用户授权。如果后续要支持多设备共享、后台统一撤销、审计日志、权限分级，就应该把凭据迁移到数据库表，按用户 ID 关联，并增加授权记录和失效机制。

这次维护的重点，是先把前后端分离场景下最危险的那条线收住：Application Password 不进前端 JS，不在浏览器里明文保存，所有高权限 WordPress REST 调用都回到服务端处理。