停止向用户泄露抠图模型 #120
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: GenarrativeAI/Genarrative#120
Reference in New Issue
Block a user
Delete Branch "fix/show_model"
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?
[P1] 历史“抠图模型”字段仍会泄露。
ImageCanvasGenerationModel.ts (line 557) 只过滤“处理模型”，但历史兼容数据明确使用“抠图模型”，见 ImageCanvasGenerationDialogModel.test.ts (line 526)。旧项目的信息弹窗和 ZIP 导出仍会展示 动漫风格 anime-seg。应同时过滤两种标题，并补弹窗、导出回归测试。
这是一个虚假问题，历史图片继续显示旧字段无任何不妥
[P2] 内部模型仍参与素材和图层搜索。
ImageCanvasAssetLibraryModel.ts (line 212) 和 ImageCanvasAssetLibraryModel.ts (line 225) 仍索引原始 model。例如手动去背景保存的 BgFilter complex 可以通过搜索命中素材，即使详情显示为 -，仍形成可观察泄漏及“命中但无可见匹配字段”的异常体验。内部模型不应进入搜索索引。
不违反契约，不构成问题。
当前审计依赖现有实现，先不改
[P1] 新增内部抠图元数据会进入匿名精选接口。 editor_project.rs:2295 将 mattingProvider/mattingModel 写入 generationInputs；素材提交精选时原样快照，公开 mapper 在 6318 行 只清理内联媒体。匿名 GET /api/editor/showcase/resources 因而可直接看到 BgFilter/birefnet、Aliyun Matting/segment-common-image 等内部实现。应仅在 public payload 边界移除内部键，保留 owner/admin 审计读取。
[P1] 历史“抠图模型”仍会直接展示和导出。 ImageCanvasGenerationModel.ts:557 只过滤“处理模型”，但现有历史 fixture 明确使用“抠图模型 = 动漫风格 anime-seg”。信息弹窗和 ZIP metadata 都会保留它。作者虽在评论中认为历史字段可以显示，但这与当前文档“前端用户路径不展示抠图模型”的口径冲突；若确实要例外，应先明确收窄契约。
[P2] 隐藏模型仍参与素材和图层搜索。 ImageCanvasAssetLibraryModel.ts:212 和 225 行 仍索引 raw model，会出现“搜索命中、界面却没有任何可见匹配字段”的异常，也可侧向判断内部模型。
[P1] 历史“抠图模型”仍会直接展示和导出。 ImageCanvasGenerationModel.ts:557 只过滤“处理模型”，但现有历史 fixture 明确使用“抠图模型 = 动漫风格 anime-seg”。信息弹窗和 ZIP metadata 都会保留它。
明确不改
只涉及历史素材的都不改，模型泄露不是强安全问题
[P1] External OpenAPI v1 出现未版本化 breaking change。 PR 从同一个 v1 / 1.0.0 的图片、图集、视频、音频生成响应中删除原本 required 的 provider，例如 EditorImageGenerationResponse。现有严格反序列化或 OpenAPI 生成客户端会直接失败。脱敏目标合理，但应提供兼容响应、弃用周期或升级 API 版本。
[P1] 历史“抠图模型”仍直接展示和导出。 ImageCanvasGenerationModel.ts:557 仍只过滤“处理模型”，而历史 fixture 明确存在“抠图模型 = 动漫风格 anime-seg”。Owner mapper 不清理 fields，因此信息弹窗和 ZIP metadata 仍暴露。作者已明确表示历史素材不改，所以这是当前文档契约与产品决定的显式冲突。
[P2] 手动去背景新增重复全量读取。 解析 object key 所有权时已经遍历账号全部项目/素材；随后 resolve_editor_background_removal_source_model 又无条件重新读取全部项目和完整素材库。账号数据增大后，每次去背景都会重复传输全部画布、资源和素材快照。应合并解析过程或增加按资源/素材/object key 定向查询。
[P1] External API 仍可执行未公开的 segModel
external_editor_api.rs (line 612)
三个 External handler 直接复用站内 DTO，因此 API Key 调用方仍可手写 segModel: "anime-seg" 并实际传给 BgFilter。OpenAPI 的 additionalProperties: false 不提供运行时校验。应使用 External 专用 DTO，或明确拒绝该字段
API Key 调用方仍可手写 segModel: "anime-seg" 与契约不冲突
[P2] 模型为空时未沿来源资源恢复正常模型
ImageCanvasEditorModel.ts (line 789)
后端会删除派生资源上的内部模型，导致 persistedModel 为空；当前代码随即返回，不再沿 sourceResourceId 查找祖先资源的 gpt-image-2 等正常模型。历史素材刷新后详情和 ZIP 会显示 -。
已修复
[P1] External OpenAPI v1 出现未版本化 breaking change。 PR 从同一个 v1 / 1.0.0 的图片、图集、视频、音频生成响应中删除原本 required 的 provider，例如 EditorImageGenerationResponse。现有严格反序列化或 OpenAPI 生成客户端会直接失败。脱敏目标合理，但应提供兼容响应、弃用周期或升级 API 版本。
目前阶段不需要考虑兼容性问题
docs/technical/【前端架构】图片画布编辑器MVP接入方案-2026-06-11.md:178 — 把「前端同时过滤历史项目中已持久化的处理模型字段」这句从全覆盖承诺降级为事实描述：过滤是标题精确匹配 处理模型，不做语义识别；「抠图模型」是已知例外，会继续出现在图片信息与 ZIP；这是接受状态而非缺陷；约束只对新写入生效。
[P1] 外部 API 仍直接复用站内请求 DTO。API Key 调用方可提交未公开的 segModel: "anime-seg" 并实际执行；但权威 OpenAPI 未声明该字段且设置了 additionalProperties: false。这既违反外部契约，也没有真正隔离内部抠图模型。应使用外部专用 DTO 并拒绝该字段。位置：external_editor_api.rs。