WonderableAI/shaguabijia-app-server
11
0
Fork 0
Code Issues Pull Requests 16 Actions Packages Projects Releases Wiki Activity

功能：统一限制策略与白名单管理 #207

Merged
guke merged 8 commits from codex/limit-policy-whitelist into main 2026-07-31 17:08:07 +08:00
Conversation 4 Commits 8 Files Changed 34
+5160 -209
linkeyu commented 2026-07-30 20:25:15 +08:00
Member
Copy Link
Copy Source

需求背景

将比价、短信与登录、广告、引导与账号、风控免告警等限制统一配置，并支持按手机号或设备设置有有效期的临时白名单。

主要改动

  • 新增统一限制策略注册表、全局 JSON 配置与白名单覆盖表
  • 新增白名单管理、设备检索、批量追加与主体统一编辑接口
  • 接入比价、短信登录、广告奖励、引导视频、账号换绑及风险告警调用链
  • 保留旧配置接口兼容，并同步统一策略全局值
  • 增加单主体唯一有效期、恢复全局、审计日志和风险事件自动处理
  • 增加数据库迁移及完整回归测试

验证

  • 白名单、权限、配置及风控测试 50 项通过
  • 短信、登录、比价、广告关联测试 98 项通过
  • Ruff 与 Python 编译检查通过
  • Alembic 保持单一 head
  • 已同步最新 main
## 需求背景 将比价、短信与登录、广告、引导与账号、风控免告警等限制统一配置，并支持按手机号或设备设置有有效期的临时白名单。 ## 主要改动 - 新增统一限制策略注册表、全局 JSON 配置与白名单覆盖表 - 新增白名单管理、设备检索、批量追加与主体统一编辑接口 - 接入比价、短信登录、广告奖励、引导视频、账号换绑及风险告警调用链 - 保留旧配置接口兼容，并同步统一策略全局值 - 增加单主体唯一有效期、恢复全局、审计日志和风险事件自动处理 - 增加数据库迁移及完整回归测试 ## 验证 - 白名单、权限、配置及风控测试 50 项通过 - 短信、登录、比价、广告关联测试 98 项通过 - Ruff 与 Python 编译检查通过 - Alembic 保持单一 head - 已同步最新 main
linkeyu added 4 commits 2026-07-30 20:25:16 +08:00
功能：统一限制策略与白名单管理 3f2ec19ec2 
新增统一限制规则、临时不限和风控免告警白名单，接入比价、短信登录、广告、引导视频与账号冷却等业务链路。补充设备选择、权限、审计、迁移及回归测试。
Merge remote-tracking branch 'origin/main' into codex/limit-policy-whitelist 125f0e1a37 
# Conflicts:
#	app/admin/routers/guide_video.py
#	app/models/guide_video.py
#	app/repositories/guide_video.py
#	app/schemas/guide_video.py
修复：完善白名单配置兼容与审计一致性 fdbf7a893b
合并：同步最新主分支 c67407668e
linkeyu commented 2026-07-30 20:26:02 +08:00
Author
Member
Copy Link
Copy Source

配套前端 PR：WonderableAI/shaguabijia-admin-web#99

配套前端 PR：https://gitea.shaguabijia.com/WonderableAI/shaguabijia-admin-web/pulls/99
guke commented 2026-07-30 20:53:00 +08:00
Member
Copy Link
Copy Source

🤖 review-pr 深审结论

🟡 需关注（置信度 0.82）—— 核心框架健壮、迁移单 head、50 核心测试过、零回归；但强烈建议先协调 #204/#205 合并顺序（同文件交叉），且 codex 5040 行建议人工复核业务语义。

改动：统一限制策略框架（limit_policy.py 629 行 / 16 规则注册表）+ 白名单管理（模型·迁移·repo·router·schema）+ 接入 8 条调用链 + 2 个 alembic 迁移。

核心框架核对（limit_policy.py）

  • 16 规则 RuleDefinition 注册表；resolve 全局+override，device>phone 优先级；有效期 _aware 时区安全；set_global_limits with_for_update 原子更新 + 清理旧稀疏行防双真值源；legacy 平滑兼容；白名单仅 unlimited/suppress_alert（不覆盖具体值）；设备跨来源防误套；validate_override 校验完备（临时白名单必设失效、失效>生效>now、免告警限 alert_only）。

迁移：guide_video_ten_circle_v2 → limit_policy_whitelist → limit_policy_global_bundle，alembic heads 实跑 = 单 head ✓。

测试（实跑 .venv 合并后）

  • ✅ 核心 50 passed（test_limit_whitelist/admin_config/admin_roles/risk_monitor）
  • ✅ 零回归：全量 656 passed / 10 failed / 5 errors，经 base(origin/main) 对比确认 15 个失败全为仓库既有（失败集合完全一致）；#207 未引入新失败，反而 +50 passed。

⚠️ 并行 PR 交叉冲突（不阻塞但需协调）

  • #207 改的 sms/__init__.py（旧版无 fallback）与 #204 冲突；ad_reward/ad_feed_reward 与 #205 交叉；auth.py 与 #204 交叉。三个 open PR 基于不同 main 快照、互不含对方改动。
  • 合并顺序会产生冲突：后合并者需 rebase 解决（如 sms/__init__.py 既要 #204 fallback 又要 #207 限制接入；ad_reward 既要 #205 floor 又要 #207 接入），rebase 后务必复跑测试。

info

  • 仓库 origin/main 已有 10 failed + 5 errors（test_guide_video/test_invite_compare_reward/test_push_center 等）——与本 PR 无关，建议另行清理。
  • 超大 codex PR（5040 行）未逐行审：聚焦核心框架 + 迁移 + 接入测试；16 规则阈值与 8 条接入链业务语义建议团队再人工确认。

— 🤖 review-pr 自动深审 @linkeyu

## 🤖 review-pr 深审结论 🟡 **需关注**（置信度 0.82）—— 核心框架健壮、迁移单 head、50 核心测试过、**零回归**；但**强烈建议先协调 #204/#205 合并顺序**（同文件交叉），且 codex 5040 行建议人工复核业务语义。 **改动**：统一限制策略框架（`limit_policy.py` 629 行 / 16 规则注册表）+ 白名单管理（模型·迁移·repo·router·schema）+ 接入 8 条调用链 + 2 个 alembic 迁移。 **核心框架核对（limit_policy.py）** - 16 规则 `RuleDefinition` 注册表；`resolve` 全局+override，**device>phone 优先级**；有效期 `_aware` 时区安全；`set_global_limits` `with_for_update` 原子更新 + 清理旧稀疏行防双真值源；legacy 平滑兼容；白名单仅 `unlimited`/`suppress_alert`（不覆盖具体值）；设备跨来源防误套；`validate_override` 校验完备（临时白名单必设失效、失效>生效>now、免告警限 alert_only）。 **迁移**：`guide_video_ten_circle_v2 → limit_policy_whitelist → limit_policy_global_bundle`，`alembic heads` 实跑 = **单 head** ✓。 **测试（实跑 .venv 合并后）** - ✅ 核心 **50 passed**（`test_limit_whitelist`/`admin_config`/`admin_roles`/`risk_monitor`） - ✅ **零回归**：全量 656 passed / 10 failed / 5 errors，经 base(origin/main) 对比确认 **15 个失败全为仓库既有**（失败集合完全一致）；#207 未引入新失败，反而 +50 passed。 **⚠️ 并行 PR 交叉冲突（不阻塞但需协调）** - #207 改的 `sms/__init__.py`（旧版无 fallback）与 **#204** 冲突；`ad_reward`/`ad_feed_reward` 与 **#205** 交叉；`auth.py` 与 #204 交叉。三个 open PR 基于不同 main 快照、互不含对方改动。 - **合并顺序会产生冲突**：后合并者需 rebase 解决（如 `sms/__init__.py` 既要 #204 fallback 又要 #207 限制接入；`ad_reward` 既要 #205 floor 又要 #207 接入），rebase 后务必复跑测试。 **info** - 仓库 origin/main 已有 10 failed + 5 errors（`test_guide_video`/`test_invite_compare_reward`/`test_push_center` 等）——与本 PR 无关，建议另行清理。 - 超大 codex PR（5040 行）未逐行审：聚焦核心框架 + 迁移 + 接入测试；16 规则阈值与 8 条接入链业务语义建议团队再人工确认。 — 🤖 review-pr 自动深审 @linkeyu
linkeyu added 1 commit 2026-07-31 12:00:08 +08:00
合并：同步短信容灾与广告发奖主分支更新 085d610c99 
# Conflicts:
#	app/api/v1/auth.py
#	app/integrations/sms/__init__.py
guke commented 2026-07-31 12:51:55 +08:00
Member
Copy Link
Copy Source

🤖 review-pr 增量复审（c674 → 085d）

🟢 可合并 · 置信度 0.85（上轮 🟡 的「合并顺序冲突」已解决）—— 作者 merge 了 main(#204/#205)，冲突解决正确、测试全过。

新提交：085d610 merge commit（同步 main 含已合并的 #204 sms fallback + #205 rewards floor）。#207 自身 limit 逻辑未变。

核对

  • ✅ merge 解决正确：sms/__init__.py 现兼具 #204 的 fallback（send_code→SendResult / 503 转备 / verify try-both）+ #207 的 limit 接入（在 auth/ratelimit 层）；无残留冲突。
  • ✅ 测试 58 passed（test_sms_fallback + sms_dispatch + sms_base + limit_whitelist + auth）——sms 容灾与统一限制共存无碍。
  • 上轮 🟡 的「与 #204/#205 同文件交叉」已消解（本 PR 已 merge 它们）。

剩余关注（info）

  • codex 5040 行业务语义（16 规则阈值 + 8 接入链）仍建议团队人工复核（上轮提的，未变）。
  • 迁移分叉：#207 limit_policy_whitelist 与 #208 push_binding_isolation 同 down_revision(guide_video_ten_circle_v2)，两者谁后合并需 rebase down_revision，否则 alembic 双 head。

风险 🟢（合并冲突已清、测试全过；codex 语义复核 + 与 #208 迁移分叉留意）。

— 🤖 review-pr 自动深审 @linkeyu

## 🤖 review-pr 增量复审（`c674` → `085d`） 🟢 **可合并** · 置信度 0.85（上轮 🟡 的「合并顺序冲突」已解决）—— 作者 merge 了 main(#204/#205)，冲突解决正确、测试全过。 **新提交**：`085d610` merge commit（同步 main 含已合并的 #204 sms fallback + #205 rewards floor）。#207 自身 limit 逻辑未变。 **核对** - ✅ merge 解决正确：`sms/__init__.py` 现兼具 #204 的 fallback（`send_code`→`SendResult` / 503 转备 / verify try-both）+ #207 的 limit 接入（在 auth/ratelimit 层）；无残留冲突。 - ✅ 测试 **58 passed**（`test_sms_fallback` + `sms_dispatch` + `sms_base` + `limit_whitelist` + `auth`）——sms 容灾与统一限制共存无碍。 - 上轮 🟡 的「与 #204/#205 同文件交叉」已消解（本 PR 已 merge 它们）。 **剩余关注（info）** - codex 5040 行业务语义（16 规则阈值 + 8 接入链）仍建议团队人工复核（上轮提的，未变）。 - **迁移分叉**：#207 `limit_policy_whitelist` 与 #208 `push_binding_isolation` **同 down_revision**(`guide_video_ten_circle_v2`)，两者谁后合并需 rebase `down_revision`，否则 alembic 双 head。 风险 🟢（合并冲突已清、测试全过；codex 语义复核 + 与 #208 迁移分叉留意）。 — 🤖 review-pr 自动深审 @linkeyu
linkeyu added 1 commit 2026-07-31 14:38:43 +08:00
修复：设备白名单支持跨分类配置 fab49da883 
设备 ID 按普通字符串处理，移除不同业务来源之间的混选限制。补充批量新增、追加和整主体替换的跨分类回归测试。
guke commented 2026-07-31 16:37:06 +08:00
Member
Copy Link
Copy Source

🤖 review-pr 增量复审（085d → fab4）

🟡 需关注（置信度 0.8）—— 设备跨分类放开本身 OK，但 #208 已合入 main 导致 alembic 双 head，合并前须 rebase 迁移。

新提交：fab49da「设备白名单支持跨分类配置」——删 validate_device_rule_scope（禁止比价/短信登录设备限制混选的校验）+ router 3 处调用 + test +95。

核对

  • ✅ 删除干净：validate_device_rule_scope 无残留引用；device_source_scope 仍被 repo 层(limit_whitelist.py:230)使用、非死代码。
  • ✅ test_limit_whitelist 24 passed（跨分类 + 既有）。
  • 设备跨分类放开是产品决策：技术上安全取决于比价/短信的 device_id 是否同源（device_source_scope 注释原防「设备 ID 跨来源误套」）；建议产品确认「同一设备同时配比价+短信白名单」的语义。

🟡 alembic 双 head（部署阻塞，须先修）

  • 上轮预警的迁移分叉已成真：#208 已合并进 main（带来 push_binding_isolation 迁移，down_revision=guide_video_ten_circle_v2）。
  • #207 的 limit_policy_whitelist down_revision 仍指 guide_video_ten_circle_v2，与 push_binding_isolation 同 parent。
  • 实测 alembic heads = 两个 head（limit_policy_global_bundle + push_binding_isolation）→ alembic upgrade head 会报 multiple heads、DB 迁移失败。
  • 修复：把 limit_policy_whitelist 的 down_revision 改为 push_binding_isolation（串成单链），或加 alembic merge 迁移。

风险 🟡（功能可上，但迁移双 head 必须合并前解决）。

— 🤖 review-pr 自动深审 @linkeyu

## 🤖 review-pr 增量复审（`085d` → `fab4`） 🟡 **需关注**（置信度 0.8）—— 设备跨分类放开本身 OK，但 **#208 已合入 main 导致 alembic 双 head，合并前须 rebase 迁移**。 **新提交**：`fab49da`「设备白名单支持跨分类配置」——删 `validate_device_rule_scope`（禁止比价/短信登录设备限制混选的校验）+ router 3 处调用 + test +95。 **核对** - ✅ 删除干净：`validate_device_rule_scope` 无残留引用；`device_source_scope` 仍被 repo 层(`limit_whitelist.py:230`)使用、非死代码。 - ✅ `test_limit_whitelist` **24 passed**（跨分类 + 既有）。 - 设备跨分类放开是产品决策：技术上安全取决于比价/短信的 device_id 是否同源（`device_source_scope` 注释原防「设备 ID 跨来源误套」）；建议产品确认「同一设备同时配比价+短信白名单」的语义。 **🟡 alembic 双 head（部署阻塞，须先修）** - 上轮预警的迁移分叉**已成真**：**#208 已合并进 main**（带来 `push_binding_isolation` 迁移，`down_revision=guide_video_ten_circle_v2`）。 - #207 的 `limit_policy_whitelist` `down_revision` **仍指 `guide_video_ten_circle_v2`**，与 `push_binding_isolation` 同 parent。 - 实测 `alembic heads` = **两个 head**（`limit_policy_global_bundle` + `push_binding_isolation`）→ `alembic upgrade head` 会报 multiple heads、DB 迁移失败。 - **修复**：把 `limit_policy_whitelist` 的 `down_revision` 改为 `push_binding_isolation`（串成单链），或加 alembic merge 迁移。 风险 🟡（功能可上，但迁移双 head 必须合并前解决）。 — 🤖 review-pr 自动深审 @linkeyu
linkeyu added 2 commits 2026-07-31 16:48:45 +08:00
合并：同步推送绑定隔离主分支更新 a40c35d41b
修复：收敛白名单迁移链 f4508863cd 
同步主分支推送绑定隔离迁移，将白名单迁移串接到 push_binding_isolation 之后，避免 Alembic 双 head 阻断部署。
guke merged commit 15fb73791f into main 2026-07-31 17:08:07 +08:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
gaomengzhuo guke kongderong linkeyu liujiahui marco wangyaoguang wanlangjie wusiyi zhuzihao zuochenyong
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: WonderableAI/shaguabijia-app-server#207
Delete Branch "codex/limit-policy-whitelist"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?