[Bug] Starred Apps API returns empty permission_keys

快速结论：这个报错出现在 Dify 自托管环境中，用户 B 在 Studio 的 Starred Apps 列表点击用户 A 维护的工作流时无法打开详情页，链接退回 {host_url}/app。根因是 /apps/starred 接口没有返回 RBAC 权限键（permission_keys 始终为空数组），导致前端无法判断当前用户是否具备 app.acl.view_layout 能力。排查时应优先确认 /apps/starred 与 /apps 对同一应用的权限返回是否不一致。[Bug] Starred Apps API returns empty permission_keys

适用环境：Dify 1.17.1，Self Hosted（Docker）部署；涉及 Studio 的 Starred Apps 列表与工作流（workflow 模式）应用；评论中引用的代码路径基于 api/controllers/console/app/app.py，未提供操作系统、Python、CUDA、显卡等具体环境信息。

最快修复方案：暂无确认的一步修复方案。该问题已被确认为后端代码缺陷，需修改 /apps/starred 接口，使其像 AppListApi（/apps）一样调用 permissions.app.permission_keys_by_resource_ids(...) 并把结果合并进响应。在官方修复合入前，可优先尝试从常规 Apps 页面打开该工作流作为临时绕过。

注意事项：仓库内评论只确认了缺陷成因，未在 Issue 中给出已验证的修复补丁或补丁版本号。修改源码属于代码变更，不是数据迁移；自行打补丁前应确认与当前版本的兼容性，并做好升级回退准备。另需注意，前端对“自己维护的工作流”存在基于 maintainer 的快捷判断，因此该问题只在跨用户收藏场景下暴露。

问题场景

用户在 Dify 1.17.1 自托管（Docker）环境中复现：用户 A 创建一个 workflow 应用；用户 B 登录后将该 workflow 加入 Starred Apps；随后在 Studio 的 Starred Apps 列表中点击该 workflow。预期跳转到 {host_url}/app/{uuid}/workflow，实际未打开工作流页面，链接回退到 {host_url}/app。对比发现，同一应用在 /apps 接口返回了完整权限键（含 app.acl.view_layout），而在 /apps/starred 中 permission_keys 为空数组。

报错原文

[Bug] Starred Apps API returns empty permission_keys

// /apps/starred 响应片段
{
  "mode": "workflow",
  "permission_keys": [],
  "maintainer": "<another_user_id>"
}

原因分析

已确认为后端接口缺陷。AppListApi.get（/apps）会用字符串形式的应用 ID 构建权限映射，并通过 permissions.app.permission_keys_by_resource_ids(app_ids) 查询权限键，再以 permission_keys_map.get(item.id, []) 合并到每个条目；而 StarredAppListApi.get（/apps/starred）从未构建或应用该权限映射，仅调用 _enrich_app_list_items 补充 access_mode 和 has_draft_trigger，因此每个条目的 permission_keys 都停留在默认空列表。

这解释了为什么表现为“与维护者相关”：前端 getRedirectionPath 只有在 getAppACLCapabilities(...).canAccessLayout 为真时才跳转到 /app/{id}/workflow。该能力要么来自真实的 app.acl.view_layout 权限键，要么来自维护者快捷判断（currentUserId === resourceMaintainer 且具有 app.create_and_management 工作区权限键）。当前用户自己维护的工作流靠快捷判断通过；他人维护的工作流拿不到真实权限键，All 检查失败，于是回退到 /app。

环境排查

确认 Dify 版本与部署方式（Issue 中为 1.17.1、Self Hosted / Docker）。
确认是否为多用户场景，且收藏的工作流由其他用户（非当前登录用户）维护。
确认该工作流模式为 workflow。
分别抓取 /apps 与 /apps/starred 对同一应用的响应，比较 permission_keys 字段。
Issue 未提供 Python、CUDA、PyTorch、显卡或依赖版本信息，无需据此排查。

解决步骤

临时绕过（可优先尝试）：从常规 Apps 页面打开该工作流，或让工作流维护者协助确认访问权限。
确认缺陷范围：对比 /apps 返回完整 permission_keys、/apps/starred 返回空数组，即可定位到 starred 接口。
代码修复（需自行承担风险）：在 api/controllers/console/app/app.py 的 starred 接口中，参考 AppListApi 的做法，调用 permissions.app.permission_keys_by_resource_ids(...) 获取权限映射，并在序列化前将结果合并进每个应用条目。
重新构建并部署修改后的后端服务。
关注官方是否已合入对应修复，优先升级到包含修复的版本。

验证方法

以用户 B 身份再次请求 /apps/starred，确认被收藏的他人维护工作流在响应中带有非空的 permission_keys，且包含 app.acl.view_layout；然后在 Studio 的 Starred Apps 列表点击该工作流，确认跳转到 {host_url}/app/{uuid}/workflow，与从常规 Apps 页面打开的行为一致。