dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
575 Commits 3 Branches 0 Tags
4eef45efe400bcd16455cb820fcc8df7188799e5
Commit Graph
18 Commits
Author SHA1 Message Date
yml2213andCursor 39388c56b5 fix(permissions): 收回客服的 CK 检测重登和自动巡检入口 
客服默认不再有 cookie:operate；自动巡检菜单改按 automation:view 显示。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-06 12:20:30 +08:00
yml2213 253571730a feat(account): 补上改备注接口，remark_changed 事件从此有发射点 
`remark_changed` 此前是「定义了事件类型、但压根没有改备注的接口」，于是永远不发。
按 S4 的原则（留着一个永远不发的类型比删掉更糟 —— 看代码的人会以为它有数据），
补接口而不是删类型。

## 接口

`PUT /api/accounts/{id}/remark`，权限点 `account:remark`（授予 super_admin /
operation / support，与 `account:tag` 一致）。

- 与改标签一样走 `record_account_action()`：**审计 + 账号时间线一次写完**，
  审计带 `account_id`，事件 detail 带 `{from, to}`；
- **只做单个、不做批量**：备注是自由文本，给一堆账号写同一句备注没有实际意义
  （标签是短枚举才有批量）；
- 内容 trim 后截断到 256（与 `accounts.remark` 列宽一致），清空也记一条事件；
- 备注没变化时直接返回、**不写事件**：否则时间线会被「点开保存了一下但没改」刷满。

## 权限点新增前的安全检查

新权限点会被 `custom_permissions` 覆盖，所以先查了库：
`admin` / `kf1_test` 的 `custom_permissions` 是 **JSON null**（不是 SQL NULL），
Python 侧取出来是 `None` → `get_user_permissions` 走角色默认。
也就是说**没有任何用户在用自定义权限列表**，新增权限点不会把谁的能力锁掉。
（这一点很容易看错：`IS NULL` 判出来是「有自定义权限」，`JSON_LENGTH` 还是 1。）

## 前端

- 详情页「备注」一行改为可编辑（铅笔 → 输入框 → 保存/取消，回车即存）；
- `EVENT_STYLE` 补 `remark_changed`，时间线里能看到备注的每次变更。

## 一个自己踩到又修掉的坑

第一版把两个 `useState` 写在了 `if (!accountId) return <Empty/>` **之后** ——
正是本次会话刚在 LoginTasksPage 修掉的那类 hooks 顺序违规（`react-hooks/rules-of-hooks`
直接报错）。已上移到早期 return 之前的 state 区块。lint 抓到，构建不报，属于
「能跑但迟早炸」的那类问题。

## 验证

- `TZ=Asia/Shanghai`：**426 passed / 6 skipped**（S4 后 420 → 新增 6 条）
- `TZ=UTC`（相关文件）77 passed；ruff check/format 全绿
- 前端 `tsc -b && vite build` 通过、`npm run lint` 0 errors
- 新增用例：写入并带 from/to 事件与审计关联、未变化不写事件、清空也记一条、
  trim + 截断到 256、账号不存在 404、**新权限点确实在三个角色的默认权限里**
  （防止「加了接口但没人能用」）
 2026-10-04 15:21:48 +08:00
yml2213 1a8710834a feat(account): S3 生命周期状态收口 —— 6 状态状态机、唯一推导入口、停用/归档闭环 
`status` 列从「空壳」变成可信状态：S1 建了列、S2 让账号独立，本提交让状态真正
反映账号处境，并把「哪些账号要人处理」变成可筛选的事实。

## 状态机（7 → 6 个状态）

`imported` / `active` / `invalid` / `manual` / `disabled` / `archived`

**砍掉 `relogin`**：它完全等价于 `invalid + relogin_next_at is not None`，
独立成状态就多出一个必须与 `relogin_next_at` 同步的字段 —— 正是要消灭的「双份真相」。

## 唯一推导入口（防「双份真相」）

新增 `services/account_lifecycle.py`：
- `derive_status(account)` —— **纯函数**，按 cookie / ck_check_status / relogin_*
  推导状态；人工态（disabled/archived）优先级最高，不被覆盖；
- `sync_status(db, account)` —— 推导 + 变了才写，**幂等**（没变则不写库、不发事件，
  否则巡检每轮都往时间线刷一条）；
- `set_manual_state(db, account, state)` —— 停用/归档/`auto`（恢复自动推导）；
- `on_login_success(db, account)` —— **「登录成功对账号意味着什么」只定义一次**：
  作废本轮重登退避痕迹 + 重算状态。于是**「待人工」的账号被人工登录救回来时状态
  会自动恢复**，而不是卡在 manual。
- `MANUAL_KINDS` 从 `jobs/ck_relogin.py` 挪到这里（service 不该反向依赖 job）。

**9 处底层判据写入点全部接线**：登录成功、CK 清除（单个/批量）、ck_health 巡检、
人工 CK 检测、工作台执行前检测、重登复检、重登结算（成功/失败退避）。

## 消费端：补上一个真缺口 + 删掉两处临时派生

- ⚠️ **缺口**：`ck_health` / `ck_relogin` / `count_pending_relogin` 此前只按底层判据
  选行，**没排除 disabled/archived** —— S2 提交里已标注，状态一上线就会变成
  「停用的账号照样被自动重登」。现已全部排除。
- `automation.manual_queue` 原本用 4 个条件自己拼「需要人工」，现在一句
  `status == 'manual'`。同一判据从「3 处各写一遍」收敛成「1 处推导」。

## 接口与前端

- `PUT /api/accounts/{id}/lifecycle`（disabled/archived/auto + 原因，写审计）
- `PUT /api/accounts/{id}/automation`（**接上死开关**：`auto_managed` 此前没有任何
  接口/前端能改，永远是默认 True）
- 新增权限点 `account:manage`（运营默认拥有）
- 列表支持 `?status=` 筛选；**归档默认不出现**（要看需显式筛选）
- `AccountOut` / 概览接口补 status / status_label / status_reason / auto_managed
- 前端：账号列表加「状态」列与状态筛选；详情页状态卡 + 停用/归档/恢复/自动化开关

## 两个自查出来的问题（都已修）

1. **幂等键反而丢事件**：状态事件一开始用 `status:{id}:{target}:{秒级时间戳}` 作
   `source_ref`，结果同一账号在同一秒内两次切到同一状态就撞唯一键，`emit` 静默吞掉
   —— **状态改了、时间线却少一条**，正是本模块要消灭的「悄悄不一致」。
   改为不传 `source_ref`：`sync_status` 本身已幂等，不存在重复写入路径。已加用例。
2. **迁移与运行时规则分叉**：迁移 0042 的状态回填 CASE 原本会写出已被砍掉的
   `relogin`，且判据与 `derive_status` 不一致（次数用尽的会回填成 invalid 而非 manual）。
   已改成逐字对应，并加一条用例**真跑那段 SQL 与纯函数逐条比对**（已验证：
   临时改回旧 CASE 该用例立刻红）。

## 验证

- `TZ=Asia/Shanghai`：**404 passed / 6 skipped**（S2 后 373 → 新增 31 条）
- 迁移链 3 passed；ruff check/format 全绿；前端 `tsc -b && vite build` 通过
- 真实开发库核对：落库状态分布 active 4 / imported 8，**与 derive_status 逐账号比对无漂移**
- 新增用例覆盖：derive 真值表（每状态入口 + 人工态优先）、sync 幂等、
  人工态切换、**全生命周期走查**（导入→登录→失效→重登→转人工→人工救回→清 CK→停用）、
  自动化排除 disabled/archived、列表状态筛选、接口

未做（后续阶段）：S4 事件发射点补齐、S5 业务事实直发事件、S6 账号页重构。
 2026-10-04 14:48:22 +08:00
yml2213 f745a61df1 feat(automation): CK 自动巡检（P1a），只检测不改 CK 
后台原本靠人工逐批点「CK 检测」发现失效账号，1.2 万个账号根本盯不过来。
P1a 把「哪些账号失效了」自动化：自动挑久未检测的账号、调现成检测接口、
把结果写回 ck_check_*。**本作业不替换任何 CK**，重登仍由人工点，符合规划里
「先做只读/只提示，确认无误再做自动动作」的渐进上线原则。

实现：
- 迁移 20261002_0037：automation_jobs / automation_runs 两张表，
  login_tasks 加 relogin_attempts / relogin_next_at / relogin_last_error
  （为 P1b 备好），accounts 加 auto_managed（特殊账号不参与自动化）；
- services/automation/scheduler.py：进程内调度线程，60s tick，状态全部落库
  （重启不丢调度进度、不重复跑轮）；AUTOMATION_ENABLED 默认关闭，作业开关
  也默认关闭；ensure_jobs 只补缺失行、不覆盖运维改过的配置；
  作业异常只记 failed，不拖垮调度线程；单容器 --workers 1，无需分布式锁；
- services/automation/jobs/ck_health.py：选行口径与人工检测一致
  （cookie_holding_filter：持有 CK 且无在途尝试），叠加久未检测、
  auto_managed、batch_size，按 ck_checked_at 升序（最久没查的优先）；
  只写 ck_check_status / ck_check_result / ck_checked_at；
- routers/automation.py：GET /jobs、PATCH /jobs/{key}、POST /jobs/{key}/run、
  GET /runs；新增权限点 automation:view（运营可看）与 automation:manage
  （仅超管），改配置与手动触发都写审计；
- 顺带补 POST /api/login/batch 的审计（此前批次是谁发起、多少账号无据可查）；
- 前端 /automation 页：作业卡片（开关/周期/单轮条数/并发）、运行历史、
  「立即跑一次」；总开关未打开、调度线程未运行时给明确提示。

验证：
- 22 条新测试覆盖调度器行为（只跑到点的、异常不抛出、下轮时间、配置不被重置）、
  选行条件（在途尝试/auto_managed/间隔/batch_size）、接口与权限，其中一条
  专门断言巡检后 cookie/status/message/attempt_status 一字未动；
- 全量 257 条通过；前端 tsc 与构建通过；
- 端到端用 3 个真实账号跑真实斗鱼接口：巡检结果与直接调 check_douyu_cookie
  逐条一致（3/3 valid），CK 与尝试状态全程未变。

顺带修掉一处会炸生产的坑：DB 时间列读出来是 naive UTC，直接与
datetime.now(UTC) 比较会 TypeError，现统一走 _as_utc() 补时区。
 2026-10-02 19:47:41 +08:00
yml2213 baed0e61ff 优化客服账号标签管理 2026-08-14 12:44:48 +08:00
yml2213 47ded2bc3e feat: add scoped cookie operations for support 2026-08-13 16:17:06 +08:00
yml2213 090698e6b2 fix: harden user management operations 2026-08-13 15:07:33 +08:00
yml2213 5074faf9f6 优化了部分支付宝界面 2026-08-12 19:12:22 +08:00
yml2213 d19c0902f2 初步增加, 扫码登录成功 2026-08-12 16:22:55 +08:00
yml2213 df4297bee5 完善客服操作台权限与绑定二维码 2026-07-25 09:45:49 +08:00
yml2213 62099e8d68 新增斗鱼活动任务模块：绑定、宝典、鱼翅、积分、兑换等功能 
- 新增 activity_client.py：封装斗鱼活动/兑换/充值/送礼接口
- 新增 cookie_utils.py：Cookie 解析与规范化工具
- 新增 douyu_service/douyu_runner：斗鱼任务服务层与批量执行器
- 新增 douyu 路由：任务类型查询、账号列表、配置管理、商品管理、批量任务、WebSocket 日志
- 新增 models/schemas：DouyuTask/DouyuConfig/DouyuGoodsSnapshot 模型，Account 扩展点数/鱼翅/绑定状态等字段
- 新增数据库迁移：斗鱼活动相关表与 accounts 字段补充
- 新增前端 DouyuTasksPage 任务操作台页面
- 兑换商品请求添加 sec-ch-ua 反检测头
- 兑换商品支持最多 8 次重试 + csrf_token 自动刷新
- 注册 douyu:task / douyu:config 权限点
- 侧边栏新增斗鱼分组与任务操作台菜单入口
 2026-07-24 16:11:39 +08:00
yml2213 cd2d02c86e 增加斗鱼账号检测功能 2026-07-09 23:12:39 +08:00
yml2213 984096f758 完善虎牙账号管理并规范Cookie 2026-07-05 13:13:38 +08:00
yml2213 e1d47a85be 新增虎牙账号和任务基础功能 2026-07-04 16:31:12 +08:00
yml2213 50f90eeeb8 实现账号信息隐藏权限系统 
1. 拆分 account:view_all 和 account:view_full 权限
2. 运营只能看用户名、标签、分配，隐藏密码/邮箱等敏感信息
3. 管理员可看完整字段（需 account:view_full 权限）
4. 所有人都可分配账号给客服
5. 前端添加上传时间列
 2026-06-24 22:15:46 +08:00
yml2213 453a637480 refactor: 修复9项中等架构问题 
安全修复:
- WebSocket 端点添加认证（cookie/token），防止未授权窃听日志
- SPA serve_spa 添加路径遍历防护（resolve + relative_to 检查）
- Token 改用 httpOnly Cookie 存储，移除前端 localStorage token（防 XSS 窃取）
- 添加安全响应头中间件（X-Content-Type-Options/X-Frame-Options/Referrer-Policy）
- HTTP 请求日志脱敏请求体中的 password/secret/token 等敏感字段
- 权限检查统一使用 user_has_permission（考虑自定义权限，修复 has_permission 忽略 custom_permissions 的缺陷）

性能与稳定性:
- cookies.py 列表接口修复 N+1 查询（改为批量查询 Account）
- login_service.py run() 结束时关闭 DB Session（防止连接泄漏）
- _active_batches/_active_tests 全局字典添加 threading.Lock（防止并发竞态）

配置优化:
- CORS 源支持环境变量 CORS_ORIGINS 配置
- Uvicorn reload 支持环境变量 UVICORN_RELOAD 控制（生产环境默认关闭）
- Cookie 安全标志支持环境变量 COOKIE_SECURE 配置（HTTPS 部署时启用）
- logs.py 权限不足返回 HTTP 403（原来返回 200 + message）
 2026-06-23 06:51:01 +08:00
yml2213 8771d91a30 优化权限控制 2026-06-22 17:07:29 +08:00
yml2213 347edb8103 初步增加 web 界面 2026-06-22 13:11:15 +08:00