关于casbin使用的疑问
问题描述
本人再接触casbin之前，一直是使用的thinkrbac那种鉴权的方式，目前在用webman做后台管理，在权限这块出于好奇选择的casbin，使用期间由于一些自身错误的理解也得到了插件作者的帮助（再次感谢），在即将完成鉴权功能的时候，新的问题就出现了，首先用户-角色，角色-菜单，这种设计的方式我还是按接触casbin之前的理解做的，这样设计会有如下几点问题：
- 如果菜单表变动（增删） 需要同步角色-菜单关联表，casbin规则表
- 如果角色表变动，同样需要同步casbin规则表
当然以上的两点问题很好解决，接下来就是登陆鉴权，但是这里又产生了新的疑问，如果仅仅是使用casbin鉴权，并不能保证认证的可信度，因为菜单表根角色表都是具备状态属性的，也就是这个用户即使casbin鉴权通过了，仍然需要做表查询操作，以确定鉴权的准确性，这样的话就需要鉴权步骤变成两步:
- casbin鉴权
- 查询数据表确定菜单状态根角色状态正常
这两步走完后，让我这个强迫症患者接受不了了，首先像tp那种rbac的鉴权方式，就是直接查表确定是否具备权限，鉴权只需1步（也就是上述的第二部），但是用的casbin后鉴权编程了两步，同样规则的维护上也增加了复杂度，那么casbin鉴权对应tp rbac那种的优势在哪里？还是我这种设计的方式存在严重的问题，因为我的思维停留在tp rbac那种设计方式上，强行结合了casbin
最后说明：首先本人不是吐槽casbin，东西几年来一直是我做后台权限向往的鉴权方式（之前一直用的fastadmin，没条件用这个），目前还是怀疑我设计的方式存在问题，希望好心人能给些建议，目前本人很痛苦（强迫症的痛苦）....
2140 3 0
3个回答
相似问题
年代过于久远，无法发表回答
Casbin 是什么？
Casbin 可以：
支持自定义请求的格式，默认的请求格式为{subject, object, action}。
具有访问控制模型model和策略policy两个核心概念。
支持RBAC中的多层角色继承，不止主体可以有角色，资源也可以具有角色。
支持内置的超级用户 例如：root 或 administrator。超级用户可以执行任何操作而无需显式的权限声明。
支持多种内置的操作符，如 keyMatch，方便对路径式的资源进行管理，如 /foo/bar 可以映射到 /foo*
Casbin 不能：
身份认证 authentication（即验证用户的用户名和密码），Casbin 只负责访问控制。应该有其他专门的组件负责身份认证，然后由 Casbin 进行访问控制，二者是相互配合的关系。
管理用户列表或角色列表。 Casbin 认为由项目自身来管理用户、角色列表更为合适， 用户通常有他们的密码，但是 Casbin 的设计思想并不是把它作为一个存储密码的容器。 而是存储RBAC方案中用户和角色之间的映射关系。
你可以认为Casbin是RBAC的超集
我还要再学习啊 这东西真强大
我迷糊过来了 这么强大的casbin不适合小后台用，小后台还是要遵循大道至简的原则，casbin做大型系统的
小后台也是用哦！嘿嘿！兄弟，能不能把你的提问排版一下，格式：https://www.workerman.net/q/7995
感觉像他这种讨论性质比较多的,不用模板也行,但是像这个
https://www.workerman.net/q/7996
我觉得确实有模板会好点
有了看起来舒服点，我有洁癖！哈哈
已排
谢谢~！
小后台没必要这么麻烦的。
虽然本人水平有限，但我遵循的原则是：能自已撸的不用插件。
做到心里有数。哈哈