请教，关于中后台 API 权限的设计方式？

[llsquaer]

最近一直在学习后台管理系统相关内容。试了好几个 admin 源码。发现在权限管理方式上大体使用上是 2 中方案。

第一种方案，使用标签的方式来管理 比如：'system:dept:list' 'system:notice:add'

使用这个方式，后端接口需要手动填写标签用于权限检测 ，并写入权限表。前端同时也需要在接口上设置这些标签。

修改权限的时候实际是在数据库中修改角色对应的权限表。

第二种方案，开发时自动生成 api 路径存入数据表，比如: get:system/dept/list post:system/notice/add

使用这种方式，后端就不用手动标注出来了，因为是直接通过路径入库。前端也不用额外添加标志，请求的 api 本来就是方式+路径

修改权限实际就是在数据库中链接角色对应的 api 表。

这两种方式，不管怎么样，最终到前端也是需要动态生成相关权限表（对象）的，只是生成的方法各有差异，按照约定规则生成就实现了前端的相应权限。

我比较喜欢第二种，因为少写一些代码嘛。没那么多心智负担。但是看了好几个项目，大多是用的第一种。

因为开发的少，所以还没想出使用第一种方式的场景。

所以来问问大佬们，两种优缺点和使用上的场景？？

[Bingchunmoli]

第一种支持范围权限吧，而且框架也都做了对应的支持 后一种还需要对路由进行遍历，大的项目路由还是很多很慢的

[Ayanokouji]

做中台遇到不懂的，直接参考飞书的。我推荐第一种
https://open.feishu.cn/document/server-docs/application-scope/scope-list

[billly]

第一种更灵活，有个很常见的场景，添加的接口可能有多种，但这多种接口都可以用 system:notice:add 来管理权限

[xuanbg]

我的方案是把需要对外发布的接口写在接口配置表里面，需要鉴权的接口就配置一下 auth_code ，类似 xxx_add 这样。然后在功能权限资源表对应的功能上同样配置这个 auth_code 。这样，只要这个功能被授权了，网关统一拦截请求，根据 url 就能知道这个接口需不需要鉴权，以及需要鉴权的话这个用户有没有权限访问。

[testcgd]

第一种，path 和需要的权限分开

[samnya]

我习惯用类似第一种的自定义标签，因为我们这里有细分按钮和字段权限，如果往 API 路径上面加后缀，那和自定义的区别已经不大了。

[CapNemo]

第二种方案存在将权限和路径绑定的问题。接口需要版本迭代或增加不同参数的版本时容易引发问题。
可以考虑将第二种方案里权限配置改为使用带通配符的路由。不过设计的太复杂又容易因为配置错误导致越权。

[twofox]

很多时候，同一个资源可能有不同的 update 方式。我倾向于拿同一个标签进行绑定，这样我也不用频繁修改用户权限

[spritecn]

第一种 更通用,谁知道产品要怎么设计,至少你说权限标签要手工写,那不就是一行的事,还有权限不仅仅控制路径,有些比如 update 时某个字段,A 权限能改,B 权限不能改的

[totoro52]

肯定第一种，模块多起来了就知道第一种的灵活性了