feat(admin): Add user management and upgrade to module permission system
Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
This commit is contained in:
@@ -1,17 +1,18 @@
|
||||
# **謚譛ｯ隶ｾ隶｡譁<EFBFBD>｡｣<EFBFBD>壼ｷ･蜈ｷ C \- 遘醍<E98198>疲焚謐ｮ郛冶ｾ大<EFBDBE>?(V7 莠醍ｫｯ豐咏ｮｱ謚鈴｣朱勦迚<E58BA6>)**
|
||||
# **技术设计文档：工具 C \- 科研数据编辑器 (V7 云端沙箱抗风险版)**
|
||||
|
||||
| 文档类型 | Technical Design Document (TDD) |
|
||||
| :---- | :---- |
|
||||
| **蟇ｹ蠎泌次蝙<EFBFBD>** | **蟾･蜈ｷC\_遘醍<E98198>疲焚謐ｮ郛冶ｾ大勣\_蜴溷梛隶ｾ隶｡\_V6\_菫ｮ螟咲<E89E9F>?html** |
|
||||
| **迚域悽** | **V7.1** (螳梧紛謾ｶ蠖墓楔譫<EFBFBD><EFBFBD>遲<EFBFBD> ADR 荳守ｺ｢髦滄｣朱勦蟇ｹ遲? |
|
||||
| **迥ｶ諤?* | Final Standard |
|
||||
| **譬ｸ蠢<EFBFBD>岼譬<EFBFBD>** | 譫<EFBFBD>ｻｺ荳荳ｪ鬮伜庄髱<EFBFBD>逧<EFBFBD>ｺ醍ｫ?Python 謨ｰ謐ｮ貂<EFBDAE>ｴ怜ｹｳ蜿ｰ縲ょ惠菫晞囿窶懈焚謐ｮ荳榊<E88DB3>蝓溪晉噪蜑肴署荳具ｼ碁夊ｿ<E5A48A> Apache Arrow 蜥梧<E89CA5>ｷ蠑丞<E8A091>遖ｻ謚譛ｯ<E8AD9B>瑚ｧ｣蜀ｳ譛榊苅遶ｯ謇ｧ陦悟ｸｦ譚･逧<EFBDA5>ｻｶ霑滉ｸ取<EFBDB8>ｼ蠑丈ｸ｢螟ｱ髣ｮ鬚倥?|
|
||||
| **对应原型** | **工具C\_科研数据编辑器\_原型设计\_V6\_修复版.html** |
|
||||
| **版本** | **V7.1** (完整收录架构决策 ADR 与红队风险对策) |
|
||||
| **状态** | Final Standard |
|
||||
| **核心目标** | 构建一个高可靠的云端 Python 数据清洗平台。在保障“数据不出域”的前提下，通过 Apache Arrow 和样式分离技术，解决服务端执行带来的延迟与格式丢失问题。 |
|
||||
|
||||
## **1\. 总体架构设计 (System Architecture)**
|
||||
|
||||
驩ｴ莠取枚莉ｶ螟ｧ蟆城剞蛻ｶ (\<20MB) 蜥瑚┳謨丞燕謠撰ｼ碁㊦逕ｨ 窶廸ode.js BFF \+ Python Microservice窶?譫ｶ譫<EFBDB6>?
|
||||
V7 譬ｸ蠢<EFBFBD>合郤ｧ<EFBFBD>?蠑募<E8A091> Apache Arrow 菴應ｸｺ蜑榊錘遶ｯ謨ｰ謐ｮ莠､謐｢譬<EFBFBD>㊥<EFBFBD>梧崛莉｣菴取譜逧?Excel 譁<>ｻｶ蜿榊､崎ｯｻ蜀呻ｼ悟ｰ<E6829F>黒谺｡莠､莠貞ｻｶ霑滉ｻ?8s 髯堺ｽ手<EFBDBD>?0.5s縲?
|
||||
### **1.1 譫ｶ譫<EFBDB6>挙謇大<E8AC87>?(V7 莨伜喧迚?**
|
||||
鉴于文件大小限制 (\<20MB) 和脱敏前提，采用 “Node.js BFF \+ Python Microservice” 架构。
|
||||
V7 核心升级： 引入 Apache Arrow 作为前后端数据交换标准，替代低效的 Excel 文件反复读写，将单次交互延迟从 8s 降低至 0.5s。
|
||||
|
||||
### **1.1 架构拓扑图 (V7 优化版)**
|
||||
|
||||
graph TD
|
||||
subgraph Client\_Layer \[用户端\]
|
||||
@@ -19,13 +20,13 @@ graph TD
|
||||
ArrowClient\[Apache Arrow JS\]
|
||||
end
|
||||
|
||||
subgraph Aliyun\_SAE \[髦ｿ驥御ｺ?Serverless 蠎皮畑蠑墓梼\]
|
||||
subgraph Aliyun\_SAE \[阿里云 Serverless 应用引擎\]
|
||||
BFF\[Node.js Web 服务 (Fastify)\]
|
||||
PythonService\[Python 隶｡邂怜ｾｮ譛榊<EFBFBD>?(FastAPI)\]
|
||||
PythonService\[Python 计算微服务 (FastAPI)\]
|
||||
end
|
||||
|
||||
subgraph Cache\_Layer \[高速缓存层\]
|
||||
Redis\_Session\[Redis (蟄?DataFrame Arrow 蠎丞<EFBFBD>蛹?\]
|
||||
Redis\_Session\[Redis (存 DataFrame Arrow 序列化)\]
|
||||
end
|
||||
|
||||
subgraph AI\_PaaS \[AI 能力层\]
|
||||
@@ -34,15 +35,15 @@ graph TD
|
||||
end
|
||||
|
||||
subgraph Cloud\_Infra \[持久化层\]
|
||||
OSS\[蟇ｹ雎｡蟄伜お (蟄?Excel 蠎墓攸)\]
|
||||
OSS\[对象存储 (存 Excel 底板)\]
|
||||
RDS\[RDS PostgreSQL (存元数据)\]
|
||||
end
|
||||
|
||||
%% 莠､莠呈ｵ?
|
||||
%% 交互流
|
||||
User\[用户\] \--\>|1. 上传| BFF
|
||||
BFF \--\>|2. 存原始Excel| OSS
|
||||
BFF \--\>|3. 预热 Session| PythonService
|
||||
PythonService \--\>|4. 蜉<EFBFBD>霓ｽ蟷ｶ霓ｬ荳?Arrow| Redis\_Session
|
||||
PythonService \--\>|4. 加载并转为 Arrow| Redis\_Session
|
||||
|
||||
User \--\>|5. AI 指令| Dify
|
||||
Dify \--\>|6. Python 代码| BFF
|
||||
@@ -60,69 +61,77 @@ graph TD
|
||||
|
||||
## **2\. 关键架构决策记录 (ADR)**
|
||||
|
||||
譛ｬ闃りｮｰ蠖穂ｺ<EFBFBD>ｸｺ菴穂ｻ寂懷燕遶?Pyodide窶晁ｽｬ蜷鯛懷錘遶ｯ豐咏ｮｱ窶晉噪蜀ｳ遲冶ｿ<E586B6>ｨ具ｼ御ｾ帛屬髦溷盾閠<E79BBE>?
|
||||
本节记录了为何从“前端 Pyodide”转向“后端沙箱”的决策过程，供团队参考。
|
||||
|
||||
### **决策点：前端运行 (WASM) vs 后端运行 (Server-side)**
|
||||
|
||||
| 扈ｴ蠎ｦ | 譁ｹ譯<EFBDB9> A<>壼燕遶?Pyodide (WASM) | 譁ｹ譯<EFBDB9> B<>壼錘遶?Python (譛ｬ譁ｹ譯? | 蜀ｳ遲也ｻ楢ｮｺ |
|
||||
| 维度 | 方案 A：前端 Pyodide (WASM) | 方案 B：后端 Python (本方案) | 决策结论 |
|
||||
| :---- | :---- | :---- | :---- |
|
||||
| **蜷ｯ蜉ｨ蟒ｶ霑<EFBFBD>** | **譫∵<EFBFBD> (15s+)**縲る怙荳玖ｽｽ \~20MB 蠑墓梼蛹<E6A2BC>ｼ檎畑謌ｷ菴馴ｪ梧栫蟾ｮ縲?| **遘貞ｼ**縲ら識蠅<E8AD98>惠譛榊苅蝎ｨ鬚<EFBDA8>Ο<EFBFBD>悟叉蠑蜊ｳ逕ｨ縲?| **蜷守ｫｯ閭?* |
|
||||
| **莠､莠貞ｻｶ霑<EFBFBD>** | **譫∝ｿｫ (\< 0.1s)**縲よ悽蝨ｰ蜀<EFBDB0>ｭ俶桃菴懶ｼ梧裏鄂醍ｻ懷ｼ髞縲?| **荳ｭ遲<EFBFBD> (0.5s)**縲る夊ｿ<E5A48A> Apache Arrow 莨伜喧蜷主庄謗･蜿励?| 蜑咲ｫｯ閭?|
|
||||
| **遞ｳ螳壽?* | **鬮倬｣朱<EFBFBD>?*縲よｵ剰ｧ亥勣 Tab 蜀<>ｭ俶怏髯撰ｼ梧<EFBDBC> OOM 蟠ｩ貅<EFBDA9>?| **鬮倡ｨｳ螳?*縲よ恪蜉｡蝎ｨ蜀<EFBDA8>ｭ伜<EFBDAD>雜ｳ<E99B9C>悟ｮｹ蝎ｨ髫皮ｦｻ<EFBDA6>悟ｴｩ貅<EFBDA9>ｸ榊ｽｱ蜩榊燕遶ｯ縲?| **蜷守ｫｯ閭?* |
|
||||
| **蠎捺髪謖?* | **譛蛾剞**縲ゆｸ肴髪謖<E9ABAA>Κ蛻<CE9A> C 謇ｩ螻募ｺ?(螯ょ､肴揩扈溯ｮ｡蠎<EFBDA1>)縲?| **譌<EFBFBD>髯<EFBFBD>**縲よ<E7B8B2><E38288><EFBFBD>?Linux 邇ｯ蠅<EFBDAF>ｼ檎函諤∝ｮ梧紛縲?| **蜷守ｫｯ閭?* |
|
||||
| **蠑蜿鷹埓蠎?* | **譫<EFBFBD>ｫ<EFBFBD>**縲る怙螟<E68099>炊 JS-Python 騾壻ｿ｡縲∝<E7B8B2>蟄倡ｮ｡逅<EFBDA1>?| **菴?*縲よ<E7B8B2><E38288><EFBFBD>?Web API 蠑蜿代?| **蜷守ｫｯ閭?* |
|
||||
| **启动延迟** | **极慢 (15s+)**。需下载 \~20MB 引擎包，用户体验极差。 | **秒开**。环境在服务器预热，即开即用。 | **后端胜** |
|
||||
| **交互延迟** | **极快 (\< 0.1s)**。本地内存操作，无网络开销。 | **中等 (0.5s)**。通过 Apache Arrow 优化后可接受。 | 前端胜 |
|
||||
| **稳定性** | **高风险**。浏览器 Tab 内存有限，易 OOM 崩溃。 | **高稳定**。服务器内存充足，容器隔离，崩溃不影响前端。 | **后端胜** |
|
||||
| **库支持** | **有限**。不支持部分 C 扩展库 (如复杂统计库)。 | **无限**。标准 Linux 环境，生态完整。 | **后端胜** |
|
||||
| **开发难度** | **极高**。需处理 JS-Python 通信、内存管理。 | **低**。标准 Web API 开发。 | **后端胜** |
|
||||
|
||||
**扈楢ｮｺ<EFBFBD>?* 驩ｴ莠寂懈焚謐ｮ蟾ｲ閼ｱ謨鞘昜ｸ披懈枚莉ｶ霎<EFBDB6>ｰ鞘晢ｼ<E699A2>**蜷守ｫｯ謇ｧ陦梧婿譯<E5A9BF>** 蝨ｨ遞ｳ螳壽ｧ縲∝<E7B8B2>螳ｹ諤ｧ蜥悟ｼ蜿第<E89CBF>譛ｬ荳雁<E88DB3>髱｢閭懷<E996AD>縲?
|
||||
## **3\. 謚譛ｯ騾牙梛荳手檮蜷?(Tech Stack Fusion)**
|
||||
**结论：** 鉴于“数据已脱敏”且“文件较小”，**后端执行方案** 在稳定性、兼容性和开发成本上全面胜出。
|
||||
|
||||
## **3\. 技术选型与融合 (Tech Stack Fusion)**
|
||||
|
||||
### **3.1 核心组件更新**
|
||||
|
||||
| 领域 | 选型 | V7 新增理由 |
|
||||
| :---- | :---- | :---- |
|
||||
| **謨ｰ謐ｮ莠､謐｢** | **Apache Arrow** | **蜈ｳ髞ｮ蜊<EFBFBD>ｺｧ**縲ら畑莠?Python 蜥?Node.js/蜑咲ｫｯ荵矩龍逧<EFBFBD>ｫ俶ｧ閭ｽ謨ｰ謐ｮ莨<EFBFBD>霎難ｼ碁∩蜈?JSON 蠎丞<E8A08E>蛹門ｼ髞<E9AB9E>?*隗｣蜀ｳ IO 蟒ｶ霑滓<E99C91>ｸ蠢<EFBDB8>**縲?|
|
||||
| **Excel 螟<EFBFBD>炊** | **openpyxl** | 譖ｿ莉｣郤?Pandas縲ら畑莠主惠蟇ｼ蜃ｺ譌?*菫晉蕗蜴溷ｧ<E6BAB7> Excel 譬ｷ蠑<EFBDB7>**<2A>亥ｦる｢懆牡縲∬ｾｹ譯<EFBDB9>ｼ会ｼ?*隗｣蜀ｳ譬ｼ蠑丈ｸ｢螟ｱ譬ｸ蠢<EFBDB8>**縲?|
|
||||
| **莨夊ｯ晉ｼ灘ｭ<EFBFBD>** | **Redis** | 逕ｨ莠取嘯蟄倡畑謌ｷ逧?DataFrame (蠎丞<EFBFBD>蛹紋ｸｺ Parquet/Arrow)<EFBFBD>碁∩蜈肴ｯ乗ｬ｡謫堺ｽ憺<EFBFBD>蜴?OSS 隸ｻ譁<EFBDBB>ｻｶ縲?|
|
||||
| **隶｡邂玲恪蜉｡** | **FastAPI \+ Celery** | 蠑募<EFBFBD> Celery 螟<EFBFBD>炊蠑よｭ･莉ｻ蜉｡<EFBFBD>碁亟豁｢髟ｿ隶｡邂鈴仆蝪<EFBFBD> HTTP 郤ｿ遞九?|
|
||||
| **数据交换** | **Apache Arrow** | **关键升级**。用于 Python 和 Node.js/前端之间的高性能数据传输，避免 JSON 序列化开销，**解决 IO 延迟核心**。 |
|
||||
| **Excel 处理** | **openpyxl** | 替代纯 Pandas。用于在导出时**保留原始 Excel 样式**（如颜色、边框），**解决格式丢失核心**。 |
|
||||
| **会话缓存** | **Redis** | 用于暂存用户的 DataFrame (序列化为 Parquet/Arrow)，避免每次操作都去 OSS 读文件。 |
|
||||
| **计算服务** | **FastAPI \+ Celery** | 引入 Celery 处理异步任务，防止长计算阻塞 HTTP 线程。 |
|
||||
|
||||
## **4\. 騾<EFBFBD>髄鬟朱勦隸<EFBFBD>ｼｰ荳主ｯｹ遲?(Red Teaming Analysis)**
|
||||
## **4\. 逆向风险评估与对策 (Red Teaming Analysis)**
|
||||
|
||||
譛ｬ闃りｯｦ扈<EFBFBD>ｮｰ蠖穂ｺ<EFBFBD>懃ｺ｢髦滓ｵ玖ｯ補昜ｸｭ蜿醍鴫逧<EFBFBD>ｽ懷惠閾ｴ蜻ｽ鬟朱勦蜿雁<EFBFBD>蟾･遞句喧隗｣蜀ｳ譁ｹ譯医?
|
||||
### **鬟朱勦荳<E88DB3>壻ｺ､莠貞ｻｶ霑溽噪窶應ｽ捺─蟠ｩ蝪娯?*
|
||||
本节详细记录了“红队测试”中发现的潜在致命风险及其工程化解决方案。
|
||||
|
||||
### **风险一：交互延迟的“体感崩塌”**
|
||||
|
||||
* **逆向拷问：** 每次 AI 操作都走 OSS 下载 \-\> Pandas 读取 \-\> 计算 \-\> 上传，单次耗时可能超过 8秒，用户无法忍受。
|
||||
* **V7 解决方案：** **Session 驻留模式 (Memory-Resident)**
|
||||
1. **初始化：** 用户上传 Excel 后，后端将其加载为 DataFrame，并序列化为 **Arrow** 格式存入 Redis (TTL 30min)。
|
||||
2. **增量交互：** 前端发送指令，Python 从 Redis 读取 Arrow 数据（毫秒级），执行 Pandas 计算，将结果写回 Redis。
|
||||
3. **轻量反馈：** 计算完成后，只返回 **前 100 行预览数据** 给前端 AG Grid 渲染。
|
||||
4. **效果：** 耗时缩短至 **0.5s \- 1s**。
|
||||
|
||||
* **騾<>髄諡ｷ髣ｮ<E9ABA3>?* 豈乗ｬ｡ AI 謫堺ｽ憺<EFBDBD>襍ｰ OSS 荳玖ｽｽ \-\> Pandas 隸ｻ蜿<EFBDBB> \-\> 隶｡邂<EFBDA1> \-\> 荳贋ｼ<E8B48B><EFBDBC>悟黒谺｡閠玲慮蜿ｯ閭ｽ雜<EFBDBD>ｿ<EFBFBD> 8遘抵ｼ檎畑謌ｷ譌<EFBDB7>豕募ｿ榊女縲?
|
||||
* **V7 隗｣蜀ｳ譁ｹ譯茨ｼ?* **Session 鬩ｻ逡呎ｨ｡蠑<EFBDA1> (Memory-Resident)**
|
||||
1. **蛻晏ｧ句喧<E58FA5><E596A7>** 逕ｨ謌ｷ荳贋ｼ<E8B48B> Excel 蜷趣ｼ悟錘遶ｯ蟆<EFBDAF><E89F86>蜉<EFBFBD>霓ｽ荳?DataFrame<6D>悟ｹｶ蠎丞<E8A08E>蛹紋ｸｺ **Arrow** 譬ｼ蠑丞ｭ伜<EFBDAD> Redis (TTL 30min)縲?
|
||||
2. **蠅樣㍼莠､莠抵ｼ?* 蜑咲ｫｯ蜿鷹∵欠莉､<E88E89>訓ython 莉?Redis 隸ｻ蜿<EFBDBB> Arrow 謨ｰ謐ｮ<E8AC90>域ｯｫ遘堤ｺｧ<EFBDBA>会ｼ梧鴬陦<E9B4AC> Pandas 隶｡邂暦ｼ悟ｰ<E6829F>ｻ捺棡蜀吝屓 Redis縲?
|
||||
3. **霓ｻ驥丞渚鬥茨ｼ?* 隶｡邂怜ｮ梧<EFBDAE>蜷趣ｼ悟宵霑泌<E99C91>?**蜑?100 陦碁｢<E7A281>ｧ域焚謐?* 扈吝燕遶?AG Grid 貂ｲ譟薙?
|
||||
4. **謨域棡<E59F9F>?* 閠玲慮郛ｩ遏ｭ閾?**0.5s \- 1s**縲?
|
||||
### **风险二：Excel 格式丢失 (The Format Loss)**
|
||||
|
||||
* **騾<EFBFBD>髄諡ｷ髣ｮ<EFBFBD>?* Pandas 逧?to\_excel 莨夐㍾鄂ｮ謇譛牙黒蜈<EFBFBD><EFBFBD>ｼ譬ｷ蠑擾ｼ悟現逕滓<EFBFBD><EFBFBD>ｳｨ逧<EFBFBD>｢懆牡蜥梧音豕ｨ莨壻ｸ｢螟ｱ縲?
|
||||
* **V7 隗｣蜀ｳ譁ｹ譯茨ｼ?* **蠎墓攸蛻<E694B8>ｦｻ遲也払 (Template Separation)**
|
||||
1. **荳贋ｼ<EFBFBD>譌ｶ<EFBFBD><EFBFBD>** 蟆<EFBFBD>次蟋?Excel 譬<EFBFBD>ｮｰ荳?**"Style Template" (譬ｷ蠑丞ｺ墓攸)**<2A>梧ｰｸ荵<EFBDB8>ｿ晏ｭ伜惠 OSS縲?
|
||||
2. **隶｡邂玲慮<EFBFBD><EFBFBD>** 蜿ｪ蝨ｨ蜀<EFBDA8>ｭ<EFBFBD>/Redis 荳ｭ螟<EFBDAD>炊郤ｯ謨ｰ謐ｮ (Values)<29>御ｸ榊<EFBDB8>蠢<EFBFBD><E8A0A2>ｷ蠑上?
|
||||
3. **蟇ｼ蜃ｺ譌ｶ<EFBFBD><EFBFBD>** 菴ｿ逕ｨ openpyxl 蜉<EFBFBD>霓ｽ窶懈<EFBFBD>ｷ蠑丞ｺ墓攸窶晢ｼ悟ｰ<EFBFBD><EFBFBD>蟄倅ｸｭ逧<EFBFBD>眠謨ｰ謐ｮ**蝪ｫ蜈･**蛻ｰ蠎墓攸逧<E694B8>ｯｹ蠎泌攝譬<E6949D>ｸｭ<EFBDB8>御ｿ晉蕗譛ｪ菫ｮ謾ｹ蛹ｺ蝓溽噪閭梧勹濶ｲ蜥梧音豕ｨ縲?
|
||||
### **鬟朱勦荳会ｼ夂憾諤∝酔豁･逧<EFBDA5>懷曙蜀吝<E89C80>遯≫?*
|
||||
* **逆向拷问：** Pandas 的 to\_excel 会重置所有单元格样式，医生标注的颜色和批注会丢失。
|
||||
* **V7 解决方案：** **底板分离策略 (Template Separation)**
|
||||
1. **上传时：** 将原始 Excel 标记为 **"Style Template" (样式底板)**，永久保存在 OSS。
|
||||
2. **计算时：** 只在内存/Redis 中处理纯数据 (Values)，不关心样式。
|
||||
3. **导出时：** 使用 openpyxl 加载“样式底板”，将内存中的新数据**填入**到底板的对应坐标中，保留未修改区域的背景色和批注。
|
||||
|
||||
* **騾<>髄諡ｷ髣ｮ<E9ABA3>?* 逕ｨ謌ｷ謇句勘菫ｮ謾ｹ莠<EFBDB9>ｬｬ 5 陦鯉ｼ悟酔譌ｶ AI 蛻<>髯､莠<EFBDA4>ｬｬ 5 陦鯉ｼ悟ｯｼ閾ｴ謨ｰ謐ｮ迥ｶ諤∽ｸ堺ｸ閾ｴ縲?
|
||||
* **V7 隗｣蜀ｳ譁ｹ譯茨ｼ?* **UI 莠呈箕髞?(UI Locking)**
|
||||
* 蠖?AI 豁｣蝨ｨ逕滓<E98095>莉｣遐∵<E98190>蜷守ｫｯ豁｣蝨ｨ隶｡邂玲慮<E78EB2>窟G Grid 蠑ｺ蛻ｶ霑帛<E99C91> **readOnly** 讓｡蠑擾ｼ悟ｹｶ蝨ｨ逡碁擇譏ｾ遉?"AI 豁｣蝨ｨ螟<EFBDA8>炊..." 驕ｮ鄂ｩ<E98482>?*迚ｩ逅<EFBDA9>ｱる擇荳顔ｦ∵ｭ｢蟷ｶ蜿第桃菴?*縲?
|
||||
### **鬟朱勦蝗幢ｼ壼ｮ牙<EFBDAE>豐咏ｮｱ騾<EFBDB1>?*
|
||||
### **风险三：状态同步的“双写冲突”**
|
||||
|
||||
* **騾<EFBFBD>髄諡ｷ髣ｮ<EFBFBD>?* AI 逕滓<E98095>莠?import os; os.system('rm \-rf /')縲?
|
||||
* **V7 隗｣蜀ｳ譁ｹ譯茨ｼ?* **AST 髱呎∝<C280>譫?\+ 螳ｹ蝎ｨ髫皮ｦｻ**
|
||||
* **鬚<>｣<EFBDA3>?* 蝨ｨ謇ｧ陦?exec() 蜑搾ｼ御ｽｿ逕ｨ Python ast 讓｡蝮玲沖謠丈ｻ｣遐∵<E98190>托ｼ梧｣豬句芦 import os 遲牙<E981B2>髞ｮ隸咲峩謗･謚帛<E8AC9A>蠑ょｸｸ縲?
|
||||
* **襍<>ｺ宣剞鬚晢ｼ?* 菴ｿ逕ｨ Python resource 讓｡蝮鈴剞蛻ｶ蜊墓ｬ｡謇ｧ陦檎<E999A6>?CPU 譌ｶ髣ｴ (10s) 蜥?蜀<>ｭ<EFBFBD> (1GB)縲?
|
||||
## **5\. 謨ｰ謐ｮ蠎楢ｮｾ隶?(蜈<>焚謐ｮ螻<EFBDAE>)**
|
||||
* **逆向拷问：** 用户手动修改了第 5 行，同时 AI 删除了第 5 行，导致数据状态不一致。
|
||||
* **V7 解决方案：** **UI 互斥锁 (UI Locking)**
|
||||
* 当 AI 正在生成代码或后端正在计算时，AG Grid 强制进入 **readOnly** 模式，并在界面显示 "AI 正在处理..." 遮罩，**物理层面上禁止并发操作**。
|
||||
|
||||
### **风险四：安全沙箱逃逸**
|
||||
|
||||
* **逆向拷问：** AI 生成了 import os; os.system('rm \-rf /')。
|
||||
* **V7 解决方案：** **AST 静态分析 \+ 容器隔离**
|
||||
* **预检：** 在执行 exec() 前，使用 Python ast 模块扫描代码树，检测到 import os 等关键词直接抛出异常。
|
||||
* **资源限额：** 使用 Python resource 模块限制单次执行的 CPU 时间 (10s) 和 内存 (1GB)。
|
||||
|
||||
## **5\. 数据库设计 (元数据层)**
|
||||
|
||||
新增 TaskAudit 表用于记录每一次 AI 操作的上下文，便于回滚和审计。
|
||||
|
||||
譁ｰ蠅<EFBFBD> TaskAudit 陦ｨ逕ｨ莠手ｮｰ蠖墓ｯ丈ｸ谺?AI 謫堺ｽ懃噪荳贋ｸ区枚<E58CBA>御ｾｿ莠主屓貊壼柱螳｡隶｡縲?
|
||||
model TaskAudit {
|
||||
id String @id @default(uuid())
|
||||
datasetId String
|
||||
version Int // 謫堺ｽ懷錘逧<EFBFBD>沿譛ｬ蜿?
|
||||
version Int // 操作后的版本号
|
||||
|
||||
actionType String // "AI\_CODE" or "MANUAL\_EDIT"
|
||||
prompt String? // 用户的自然语言指令
|
||||
code String? // AI 逕滓<EFBFBD>逧?Python 莉｣遐<EFBFBD>
|
||||
code String? // AI 生成的 Python 代码
|
||||
|
||||
executionTime Int // 执行耗时 (ms)
|
||||
status String // SUCCESS / FAILED
|
||||
@@ -132,23 +141,24 @@ model TaskAudit {
|
||||
|
||||
## **6\. API 接口定义 (V7 优化)**
|
||||
|
||||
* POST /api/session/init: 荳贋ｼ<EFBFBD>譁<EFBFBD>ｻｶ<EFBFBD>悟<EFBFBD>蟋句喧 Redis Session<EFBFBD>瑚ｿ泌<EFBFBD>?sessionId縲?
|
||||
* POST /api/session/init: 上传文件，初始化 Redis Session，返回 sessionId。
|
||||
* POST /api/session/execute:
|
||||
* **Input:** { sessionId, code, version }
|
||||
* **Output:** { previewData: ArrowBase64, newVersion: int, logs: string }
|
||||
* **隸ｴ譏<EFBFBD>:** 莉<>ｿ泌屓鬚<E5B193>ｧ域焚謐ｮ<E8AC90>御ｸ咲函謌?Excel 譁<>ｻｶ縲?
|
||||
* **说明:** 仅返回预览数据，不生成 Excel 文件。
|
||||
* POST /api/session/save:
|
||||
* **Input:** { sessionId }
|
||||
* **Output:** { downloadUrl }
|
||||
* **隸ｴ譏<EFBFBD>:** 隗ｦ蜿<EFBDA6> openpyxl 蜷亥ｹｶ騾ｻ霎托ｼ檎函謌先怙扈?Excel 蟷ｶ荳贋ｼ?OSS縲?
|
||||
## **7\. 蠑蜿大<E89CBF>蟾･蟒ｺ隶?*
|
||||
* **说明:** 触发 openpyxl 合并逻辑，生成最终 Excel 并上传 OSS。
|
||||
|
||||
* **Python 扈?(驥堺ｸｭ荵矩㍾):**
|
||||
* 螳樒鴫 Arrow \<-\> Pandas 逧<>ｺ丞<EFBDBA>蛹夜ｻ霎代?
|
||||
* 蟆∬｣<EFBFBD> openpyxl 逧<><E980A7>ｷ蠑丞屓蝪ｫ騾ｻ霎代?
|
||||
* 謳ｭ蟒ｺ FastAPI \+ Redis 邇ｯ蠅<EFBDAF>?
|
||||
* **Node.js 扈?**
|
||||
* 雍溯ｴ｣ Dify 霓ｬ蜿大柱驩ｴ譚<EFBDB4>?
|
||||
* **蜑咲ｫｯ扈?**
|
||||
* 髮<EFBFBD><EFBFBD> apache-arrow JS 蠎難ｼ瑚ｧ｣譫仙錘遶ｯ霑泌屓逧<E5B193>ｺ瑚ｿ帛宛豬∝ｹｶ蝨?AG Grid 螻慕､ｺ縲?
|
||||
* 螳樒鴫窶廣I 螟<>炊荳ｭ窶晉噪蜈ｨ螻城煤螳壻ｺ､莠偵
|
||||
## **7\. 开发分工建议**
|
||||
|
||||
* **Python 组 (重中之重):**
|
||||
* 实现 Arrow \<-\> Pandas 的序列化逻辑。
|
||||
* 封装 openpyxl 的样式回填逻辑。
|
||||
* 搭建 FastAPI \+ Redis 环境。
|
||||
* **Node.js 组:**
|
||||
* 负责 Dify 转发和鉴权。
|
||||
* **前端组:**
|
||||
* 集成 apache-arrow JS 库，解析后端返回的二进制流并在 AG Grid 展示。
|
||||
* 实现“AI 处理中”的全屏锁定交互。
|
||||
Reference in New Issue
Block a user