4 Commits

Include renames

Author	SHA1	Message	Date
butubb	fa227600fe	fix(creator): 权限开通后的状态显示 + 同步范围可选可查 ... - 权限显示：实测今天 display/status 已变成 1，但 tip 是「数据正在更新中，请耐心等待」， 作品仍是 0 条。原逻辑只在未开通时显示提示条，于是会一边写着「数据已开通」一边列不出 作品，自相矛盾。现在只要后台有话要说就显示，并按状态区分措辞。 - 同步范围：原本写死 90 天，界面上既看不见也改不了。现在可选 7/30/90/180/365/730 天， 与后端校验上限一致。 - 新增 creator_account.last_sync_days，记录上次实际使用的范围 —— 否则界面只能说 「同步过了」，说不清覆盖的是哪一段。选择器也会对齐到它，避免上次同步 1 年、这次 点一下悄悄缩回 90 天。	2026-10-08 07:52:28 +08:00
butubb	bef0a4fbde	fix(creator): 扫码成功却一直停在二维码上 + 运营改为左右布局 ... 【扫码不完成】根因是判据本身。原先读页面里的 window.__INITIAL_STATE__，而那是 页面加载那一刻的快照：监控那边的同一探针能用，是因为那台浏览器的页面加载时就已经 登录了；而扫码是加载之后才登录的 —— SPA 内部确实登进去了，但初始快照不会翻转， 于是检测永远等不到。 改成拿 cookie 直接问创作者后台 /api/galaxy/user/info 我是谁。实测这个判据很干净： 游客也会拿到 a1（所以签名算得出来），但接口直接回 401 无登录信息；只有真正登录了 才返回 user_id。所以「有 a1」什么都证明不了，后台认了才算。 顺带按 5 秒节流 —— 前端每 2 秒问一次，没必要每次都打后台接口。 【弹窗不关】成功后不自动关闭，停在二维码上会让人以为没成功。现在显示账号卡片与原话 提示，1.6 秒后自动关闭并提供一个「完成」按钮。 【已完成结果会残留】take_cookie 取走 cookie 就拆会话，而在飞的轮询会看到 _current 为空 回报 idle，把已显示的成功能擦掉。现在把结果记在模块里重复返回，关闭弹窗时清掉 —— 否则下次打开会立刻显示上次的成功。 【布局】按用户要求改成左右两栏（左账号列表、右数据面板），与监控统一，取消二级菜单。 未选过时默认选中第一个，右栏不会一开始就是空的。 测试：tests/test_creator_login.py 新增 7 例，含「游客会话永不完成」「接口不打满每次轮询」 「临时上下文用完必须关掉」。	2026-10-07 16:40:24 +08:00
butubb	5484e5a3ae	fix(creator): 详情接口用了 MySQL 5.7 不支持的 NULLS LAST ... 1064 语法错误。nullslast() 是 PostgreSQL 语法，MySQL 5.7 不认；而 MySQL 把 NULL 视为比任何值都小， 所以 DESC 本身就把它排在最后，不需要额外声明。 这个 bug 只在真机上暴露：SQLite 从 3.30 起支持 NULLS LAST，本地测试环境测不出来。	2026-10-07 16:32:53 +08:00
butubb	c2b310c7bf	feat(creator): 新增「运营」模块 —— 多账号扫码登录与创作者后台数据 ... 侧边栏在「监控」右边加了「运营」：账号列表 → 点进二级详情看该账号的数据。 【为什么是独立模块而不是监控的子视图】两者形状不同：监控是公开数据（点赞/收藏/评论/分享）的每轮快照+差分；运营是创作者后台按日期给出的曝光/观看/完播率/涨粉。凭据不同、采集方式也不同 —— 那边要浏览器登录态，这边是纯请求。硬塞进同一个模型会同时污染两边。 【扫码登录的关键差异】监控的扫码把登录态写进浏览器默认 profile（爬虫要复用）。运营要的是 cookie 字符串（纯请求够用），所以每次登录开一个**临时上下文**，扫完取出 cookie 就丢弃 —— 登第二个账号不会把第一个顶掉，也不影响监控那个登录态，十个账号互不干扰。 【决策依据】tools/probe_creator_api.py 的 Phase 0 实测：签名可自造（XYW_：MD5 → base64 → AES-128-CBC，与 xhshow 内置实现常量逐字节一致）；主站 cookie 即可认证创作者后台；接口与参数已与真实页面对齐。 后端： - api/creator/models.py: creator_account / creator_note_stat。**复用 MonitorBase**，这样 create_all 与上一轮改成元数据驱动的 _ensure_columns 会自动覆盖新表 - api/creator/signing.py: XYW_ 签名，带三条实测结论（url= 前缀、appId=ugc、401 与 406 的区别） - api/creator/client.py: 纯 httpx 客户端。字段名尚未亲眼验证过，所以写成多别名匹配；解析不出来存 None 而非 0 - api/creator/service.py: 账号 CRUD 与同步。cookie 绝不进入对外结构，只给 has_cookie - api/creator/login.py: 临时上下文的扫码登录 - api/routers/creator.py: 8 条路由，全部带鉴权 前端： - 侧边栏「运营」+ OperationView（账号列表 → 二级详情）+ AddAccountDialog - 权限状态显眼呈现：pending 时照抄后台原话「已为您申请数据权限，次日可查看」，并说明此时同步返回 0 条是正常的，不是采集失败 测试：tests/test_creator_client.py 新增 48 例，含「cookie 不得出现在对外结构里」这条不变量，以及权限未生效时空壳响应的处理。	2026-10-07 16:30:45 +08:00