20 lines
2.8 KiB
Markdown
20 lines
2.8 KiB
Markdown
# 模型密钥解密失败仍显示已配置
|
||
|
||
日期：2026-07-18
|
||
文档路径：document/development/2026-07-18/dev-logs/bugs/model-secret-decryption-status.md
|
||
|
||
## 修复记录
|
||
|
||
- 15:54：记录 bug 修复：模型密文无法由当前 `settings.key` 解密时，设置页仍根据非空密文显示“已配置”，掩盖实际不可用状态。
|
||
- Git 提交检查：`git fetch --all --prune` 成功；upstream `origin/main` 无新提交；本地 ahead 19 条，最新为 `07241b46 fix(docker): manage local postgres in default compose`、`787bc3a4 feat(platform): close AI expense value loop`、`242d68c3 feat(approval): add task workflow and waiver decisions`，另有 16 条。
|
||
- 原因：后端配置状态只判断数据库密文字段是否非空，前端本地草稿又可能覆盖服务端状态，均没有验证密文是否能用当前密钥成功解密。
|
||
- 修改：后端序列化配置时以实际解密结果计算模型、OnlyOffice JWT 与 SMTP 密码状态；解密只读取现有主密钥，不再因 GET 设置请求自动创建新 `settings.key`；前端合并本地草稿后重新应用服务端权威密钥状态；新增密钥轮换、密钥文件缺失和前端状态覆盖回归测试。
|
||
- 操作：在 `local-x-financial-linux` 容器内执行设置持久化测试、后端联合回归、前端全量回归、Ruff 和生产构建，并使用真实管理员设置页复验。
|
||
- 验证：主模型和备份模型仍显示“已配置”，当前无法解密的 Embedding 与 Reranker 准确显示“未配置”；后端联合回归 `165 passed`，前端全量回归 `821/821`，生产构建成功。
|
||
- 影响：管理员不会再被伪阳性状态误导；受影响的两个真实 API Key 仍需重新录入，或恢复与密文配套的旧密钥文件后才能恢复检索模型调用。
|
||
- 16:20：补齐已有主密钥格式与长度校验。
|
||
- Git 提交检查：`git fetch --all --prune` 成功；upstream `origin/main` 无新提交；本地 ahead 19 条，最新为 `07241b46 fix(docker): manage local postgres in default compose`、`787bc3a4 feat(platform): close AI expense value loop`、`242d68c3 feat(approval): add task workflow and waiver decisions`，另有 16 条。
|
||
- 修改：加密和解密路径统一要求已有 `settings.key` 解码后为 32 字节；非空但格式错误或长度错误的密钥直接拒绝，不再先生成无法由后续读取路径解密的密文；空文件仍按首次初始化语义生成合法密钥。
|
||
- 验证：新增非法 Base64、短密钥和空密钥文件回归；设置与管理模块后端联合回归 `176 passed`，Ruff 通过；`admin/admin + default` 实际读取状态为主模型/备份模型/OnlyOffice 已配置，Embedding/Reranker/SMTP 未配置。
|
||
- 影响：设置保存不会在损坏主密钥下产生新的不可恢复密文，读取设置也不会通过副作用掩盖密钥文件缺失。
|