|
|
c3667fe00d
|
fix(audit): 刷新令牌记录不再显示「未认证」
问题：审计列表里 POST /auth/refresh 的操作人恒为「未认证」。
根因：本接口刻意不挂 get_current_user —— 能用到这里，正是因为 access token
已过期、请求里没有 Authorization 头，JWT 依赖不执行，request.state 里
从未写入操作人。而"谁在何时尝试刷新"恰恰是该留痕的信息。
修复：
- core/security.py 新增 peek_token_identity()，与 decode_token 的唯一区别是
关闭过期校验（刷新场景令牌本就过期，若因过期解不出来还是会漏记）。
签名校验照常进行，伪造令牌解不出任何东西。
⚠️ docstring 中明确：该函数只许用于写审计字段，鉴权一律走 get_current_user
- refresh 接口解码 refresh token 取得 sub/username/display_name/role 写入 state。
refresh token 的载荷与 access token 完全一致，只有 type 字段不同。
附带效果：活动打点读的正是 request.state.audit_user，修复后刷新请求也会
被计为一次活动 —— 语义正确（会刷新说明用户正在使用）。
验证（7/7）：正常刷新记到中文人名与角色；过期令牌虽被拒 401 但仍能记到人；
伪造令牌不认人、显示未认证。历史记录不追溯。
|
2026-09-21 13:05:41 +08:00 |
|
|
|
17b2fab5ca
|
fix(audit): 补齐「退出」留痕 + 登录记录显示中文操作人
【问题①：退出动作在审计里完全不可见】
根因：后端没有 logout 接口。前端「退出」只清本地 localStorage、不产生任何
请求，中间件自然无从采集（中间件里早已预留 "logout" 动作映射，但端点没做）。
- 新增 POST /auth/logout，【仅用于留痕】。JWT 无状态，服务端本就没有可吊销
的会话，该接口不做任何令牌失效动作 —— 它存在的唯一目的，是让审计记下
「谁在何时退出了系统」。这点在 docstring 里写明，免得日后被误当安全边界。
- 挂 Depends(get_current_user)，让 JWT 依赖把操作人写进 request.state，
从而记录到真实姓名而非「未认证」
- 前端 logout 改为【先上报、后清 token】。顺序不能反：api.ts 的请求拦截器
是从 localStorage 取 token 的，清掉后就发不出这个请求了。
刻意不 await、失败也不阻断 —— 用户点「退出」必须退得掉。
【问题②：登录记录的「操作人」显示英文账号而非中文名】
根因：登录接口只写了 request.state.audit_user（账号），没写 audit_display_name
—— 那一刻还不知道显示名。前端按 display_name || user_id 渲染，于是退化成账号。
- 改为登录成功后补写 display_name / role。可行的原因是中间件在 call_next
返回【之后】才落库，此刻写 request.state 依然能被采集到。
- 失败登录走不到这一步，保持「只有账号可追责」（密码绝不落库），语义不变。
|
2026-09-21 11:20:59 +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 |
|
|
|
b71c5a2d07
|
feat: 双Token认证(Access 2h/Refresh 7d) + 通知系统(转交/驳回自动推送)
|
2026-08-07 11:44:04 +08:00 |
|
|
|
b22de514a1
|
feat: 实现后端核心业务逻辑 (Auth鉴权、二维码服务、看板与产品端点)
|
2026-08-04 17:09:47 +08:00 |
|
