|
|
42f6e242b4
|
fix(qrcode): 二维码接口去鉴权，并把 qrcode 路径排除出审计
前端以 <img src="/api/v1/products/qrcode/{sn}"> 引用该端点，而 <img> 无法携带
Authorization 头 —— 加了鉴权会让所有二维码图片加载失败（页面显示成破图），
并在审计里刷出大量 401。
去鉴权是安全的：本函数不查数据库，只校验长度并把这个字符串渲染成二维码，
没有任何业务数据泄露面（序列号本身就是调用方提供的）。也刻意不支持 ?token=
兜底 —— 把 JWT 放进 URL 会渗进访问日志、浏览器历史与 Referer，比它想解决的
问题更糟。
随之而来的副作用必须一并处理：qrcode 路径命中 _TRACKED_READ_PREFIXES 里的
/api/v1/products 前缀、又不是 bare list，会被判成「查看详情」逐条留痕。列表页
一次渲染就并发拉几十张图，逐条留痕会把审计日志塞满，真正有价值的操作反而被
淹没。故把 /api/v1/products/qrcode 加进 _IGNORED_PREFIXES。
实测：二维码正常加载；审计中不再出现 qrcode 记录。
|
2026-09-22 13:43:36 +08:00 |
|
|
|
192c8ee9cc
|
feat(audit): 扩大 GET 采集范围 + 修正动作文案
【扩大采集：核心业务数据的「查看详情」】
新增 _TRACKED_READ_PREFIXES（notifications / tasks / orders /
products / records）—— products 是补的：GET /products/scan/{sn}（扫码查询）
是整个车间最高频的读操作，不采它等于没采"活跃度"。
_should_audit 的 GET 分支改为三级判断：
敏感读(export/download/print) → 受跟踪前缀且非裸列表 → 否则不采
用 _is_bare_list 跳过「拉整个列表」：
· 列表接口被前端高频轮询（消息、任务列表尤其明显），逐条留痕会让
audit_logs 迅速膨胀，真正有价值的操作反而被淹没；
· 只有「查看详情」(/tasks/{id}) 才代表用户真的点开了某条业务数据。
判定用「去掉末尾斜杠后是否恰好等于某前缀」，天然排除查询串。
【修正文案】
- "read": "查询" → "查看详情"（前者易被误解成"随便搜了一下"）
- 新增 "mark_read": "标为已读"，并在 _SEGMENT_ACTION 补 "read" 映射 ——
否则 PUT /notifications/{id}/read 会回退到 _METHOD_ACTION(PUT→update)，
把"点开一条通知"记成"修改了某样东西"
- "refresh": "刷新令牌" → "上线"（token 2 小时一换，业务上视作一次上线）
⚠️ 两点须知：
1. notifications / orders 目录下【只有列表路由】，而列表按规则不采集，
故这两个模块不会产生查看记录 —— 后端没有"查看单条消息"的接口。
且消息列表被前端轮询，采集它反而会造成日志爆炸，跳过是正确的。
2. products 被纳入后，工人每扫一次码就多一条记录（50 人 × 每天数百次
≈ 上万条/天）。若嫌吵，去掉该前缀一行即可。
注：读接口鉴权已在上一提交补齐，故这些"查看详情"记录能正确挂上操作人。
|
2026-09-21 13:47:44 +08:00 |
|
|
|
7635802a42
|
feat(audit): 新增操作审计日志（表/中间件/查询接口）+ 角色常量收敛
背景：系统此前没有操作审计。task_logs 的 task_id 是 NOT NULL 外键，只能挂在
任务上，且全项目仅 4 处写入点 —— 登录、导出、产品增删改、收编完全不留痕。
需求方整理的问题清单里「无审计日志查看页」正源于此：不是没有页面，是没数据。
设计参考 MOM(KCGL) 的 audit_logs / audit_listener，但按 Track 栈做了取舍：
1) 写入时机：MOM 用 SQLAlchemy event listener + 同事务写入，优点是零侵入，
缺点是**业务回滚时审计一起消失**，而失败/被拒的操作（越权尝试、参数错误）
恰恰最需要留痕。Track 改为响应生成后用**独立 session** 写入：
- 业务回滚不影响审计（已验证 422/401 失败操作同样落库）
- 审计写入失败也不影响业务（全包裹 try/except）
- 代价：非原子提交，响应后进程立即被 kill 可能丢一条（已注释说明取舍）
2) 采集方式：中间件自动采集写操作 + 导出/下载/打印这类「读但敏感」的 GET。
路径段推导 module/action/target_id。不做手写埋点，因为手写必然漏 ——
task_logs 只有 4 处写入点就是前车之鉴。
3) 增量价值：新增 request_id 字段，与 core/logging.py 的结构化日志打通，
凭一个 ID 就能从审计记录直接跳到那一次接口日志。MOM 无此字段。
4) 敏感信息：details 经 sanitize_details 递归剔除 password/token/secret 等键；
中间件不读请求体，登录明文密码不会落库（已断言表内无密码痕迹）。
配套改动：
- core/roles.py：角色常量与 is_admin 收敛为单一事实来源。此前同一份
「管理员角色」规则散在 task_service、products.py 内联判断和前端
constants/task.ts 三处，已因此发生过「移动端漏判 SUPERVISOR 误挡主管」。
task_service 改为从 core.roles 导入同名常量，保持既有引用可用。
- core/deps.py：抽出 require_roles/require_admin 可复用依赖，替代内联判断。
- main.py：500 响应显式补 X-Request-ID 头 —— 该响应由 ServerErrorMiddleware
生成，位于 RequestContextMiddleware 外层，中间件没机会写头。
- auth.py：登录校验前把「尝试的账号」写入 request.state，使登录事件
（含失败登录）可归属到人，可用于追踪暴力破解。
验证：本地起 PostgreSQL 17 + 迁移后跑端到端测试，32/32 通过
（TestClient 每个请求新建事件循环，与模块级 asyncpg 连接池冲突会报
"got Future attached to a different loop"，故改用 httpx.AsyncClient +
ASGITransport 单循环；生产 uvicorn 单循环无此问题）。
|
2026-09-21 02:23:19 +00:00 |
|
