如题：错误原因是调用了 /api/v1alpha1/configmaps/system 获取主菜单，但没有权限
/api/v1alpha1/configmaps/system
Originally posted by @guqing in #6462 (comment)
2eafrhcq1#
我的建议是专门为主菜单信息的获取和更新提供接口，毕竟菜单管理权限强依赖 ConfigMap 的权限并不合理。
b4lqfgs42#
/kind improvement/milestone 2.19.x
huus2vyu3#
我感觉可以单独为设置项出一个自定义 API 可以根据 group 来获取，这样就可以将权限绑定到 Menu 管理权限上，每个地方都为获取配置出两个自定义 APIs 感觉很繁琐
eqzww0vc4#
专门给 system 的 ConfigMap 提供接口吗？还是 metadata.name 也可以传入
sxissh065#
GET/PUT /apis/console.api.halo.run/configmaps/{name}/{groupName}或者 /apis/console.api.halo.run/systemconfigmaps/{groupName} ,但我更倾向于方案二，方案一中 subresource 是动态的，动态的子资源路径虽然可以实现，但在 kubernetes 中不太常见,可能不完全符合 Kubernetes API 规范
/apis/console.api.halo.run/configmaps/{name}/{groupName}
/apis/console.api.halo.run/systemconfigmaps/{groupName}
5条答案
按热度按时间2eafrhcq1#
我的建议是专门为主菜单信息的获取和更新提供接口，毕竟菜单管理权限强依赖 ConfigMap 的权限并不合理。
b4lqfgs42#
/kind improvement
/milestone 2.19.x
huus2vyu3#
我的建议是专门为主菜单信息的获取和更新提供接口，毕竟菜单管理权限强依赖 ConfigMap 的权限并不合理。
我感觉可以单独为设置项出一个自定义 API 可以根据 group 来获取，这样就可以将权限绑定到 Menu 管理权限上，每个地方都为获取配置出两个自定义 APIs 感觉很繁琐
eqzww0vc4#
我感觉可以单独为设置项出一个自定义 API 可以根据 group 来获取，这样就可以将权限绑定到 Menu 管理权限上，每个地方都为获取配置出两个自定义 APIs 感觉很繁琐
专门给 system 的 ConfigMap 提供接口吗？还是 metadata.name 也可以传入
sxissh065#
我感觉可以单独为设置项出一个自定义 API 可以根据 group 来获取，这样就可以将权限绑定到 Menu 管理权限上，每个地方都为获取配置出两个自定义 APIs 感觉很繁琐
专门给 system 的 ConfigMap 提供接口吗？还是 metadata.name 也可以传入
GET/PUT
/apis/console.api.halo.run/configmaps/{name}/{groupName}或者
/apis/console.api.halo.run/systemconfigmaps/{groupName},但我更倾向于方案二，方案一中 subresource 是动态的，动态的子资源路径虽然可以实现，但在 kubernetes 中不太常见,可能不完全符合 Kubernetes API 规范