feat: 审计中心支持场景隔离-计算平台个人数据表授权管理 --story=133445738

[dkdicj]

No description provided.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 81.73653% with 61 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.80%. Comparing base (0af4193) to head (0a7298e).

Files with missing lines	Patch %	Lines
...rc/backend/services/web/strategy_v2/serializers.py	60.21%	37 Missing ⚠️
...rc/backend/services/web/strategy_v2/utils/table.py	27.27%	24 Missing ⚠️

Additional details and impacted files

@@                       Coverage Diff                       @@
##           feature/personal_data_table    #1601      +/-   ##
===============================================================
- Coverage                        86.84%   86.80%   -0.04%     
===============================================================
  Files                              837      837              
  Lines                            51104    51418     +314     
===============================================================
+ Hits                             44379    44632     +253     
- Misses                            6725     6786      +61     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[0RAJA]

Code Review

结论：有阻塞问题，建议修复后再合入。

严重问题

1. bk_username 可由请求方传入，可能枚举/触发授权其他用户的个人结果表

位置：src/backend/services/web/strategy_v2/serializers.py 的 ListTablesRequestSerializer.bk_username，以及 src/backend/services/web/strategy_v2/utils/table.py 的 MineBizRtTableHandler.__init__。

MineBizRtTableHandler 优先使用请求入参 bk_username，为空时才取当前登录用户。调用方可以传任意用户名查询其 /result_tables/mine/ 结果，并且后续 _ensure_project_permission 还会基于这些结果表做项目授权。建议删除外部入参 bk_username，服务端强制使用 get_request_username()；如果确实需要代查，必须加管理员权限校验。

2. ListTables 缓存不是用户维度，会串用户个人结果表

位置：src/backend/services/web/strategy_v2/resources.py 的 ListTables.cache_type。

新增的 MineBizRt 结果依赖当前用户，但 cache_type = CacheTypeItem(..., user_related=False)。正常不传 bk_username 时，不同用户会用相同请求参数命中同一缓存，A 用户的个人授权表可能返回给 B 用户。建议对该接口关闭缓存，或至少改为 user_related=True 并确保 cache key 包含真实当前用户。

一般问题

3. 查询列表接口带写权限副作用，且授权范围过宽

位置：src/backend/services/web/strategy_v2/utils/table.py 的 list_tables -> _ensure_project_permission。

仅浏览个人有权限结果表时，会对该业务返回的所有 RT 执行项目授权。列表接口不建议扩大项目权限。建议改到策略/联表保存时，只对实际选中的 RT 授权；授权失败时明确失败。

[0RAJA]

复审结果

本轮调整已修复上次两个严重问题：

• bk_username 不再从请求入参读取，改为服务端取当前登录用户。
• ListTables 缓存已改为 user_related=True，避免个人结果表缓存串用户。

仍建议确认/处理上次的一般问题：MineBizRtTableHandler.list_tables() 仍会在列表查询过程中调用 _ensure_project_permission()，对当前用户可见的结果表批量做项目授权。这个接口是查询列表，但会产生权限写入副作用，且授权范围是该业务返回的全部 RT，而不是用户最终选中的 RT。建议放到策略/联表保存时，只对实际选中的 RT 做授权，并在授权失败时明确失败。

除上述点外，暂未发现新的阻塞问题。

[0RAJA]

再次复审结果

这版已经把项目授权从 MineBizRtTableHandler.list_tables() 移走，列表接口不再有写权限副作用，这个方向是对的。

但当前保存路径里还有两个需要修的问题：

1. 项目授权发生在用户权限校验之前

位置：src/backend/services/web/strategy_v2/serializers.py 中 StrategySerializer._validate_strategy_data_permission() 和 LinkTableDataPermissionMixin._validate_link_table_data_permission()。

现在逻辑是先调用 _ensure_project_permission()，再判断 RT 是否在场景范围内/当前用户是否有个人查询权限。这样如果用户提交一个不在场景范围且自己无权的 rt_id，校验最终会失败，但项目授权调用已经先执行了。

建议顺序改成：

1. 先判断是否在场景授权范围内。
2. 不在场景范围时，先 _check_user_table_permission()。
3. 只有场景范围通过或用户权限通过后，再 _ensure_project_permission()。

同时补测试：用户无权限时，_ensure_project_permission 不应被调用。

2. _ensure_project_permission() 调 project_data_batch_add 时丢了 bk_biz_id

原来列表里授权时传了当前业务的 bk_biz_id，现在迁移到保存阶段后只传了 project_id/object_ids。但 ProjectDataBatchAddReqSerializer 的 bk_biz_id 默认是 settings.DEFAULT_BK_BIZ_ID，个人结果表可能来自任意业务，这里会导致非默认业务 RT 授权失败或使用错误业务 ID。

建议从 RT 元数据里获取 bk_biz_id 后按业务分组调用 project_data_batch_add，或者让前端提交并由后端校验 bk_biz_id 与 RT 一致。