这两天用casbin的总结

864328615

本人再接触casbin之前,一直是使用的thinkrbac那种鉴权的方式,目前在用webman做后台管理,在权限这块出于好奇选择的casbin,使用期间由于一些自身错误的理解也得到了插件作者的帮助(再次感谢),在即将完成鉴权功能的时候,新的问题就出现了,首先用户-角色,角色-菜单,这种设计的方式我还是按接触casbin之前的理解做的,这样设计会有如下几点问题:

  1. 如果菜单表变动(增删) 需要同步角色-菜单关联表,casbin规则表
  2. 如果角色表变动,同样需要同步casbin规则表

当然以上的两点问题很好解决,接下来就是登陆鉴权,但是这里又产生了新的疑问,如果仅仅是使用casbin鉴权,并不能保证认证的可信度,因为菜单表根角色表都是具备状态属性的,也就是这个用户即使casbin鉴权通过了,仍然需要做表查询操作,以确定鉴权的准确性,这样的话就需要鉴权步骤变成两步:

  1. casbin鉴权
  2. 查询数据表确定菜单状态根角色状态正常

这两步走完后,让我这个强迫症患者接受不了了,首先像tp那种rbac的鉴权方式,就是直接查表确定是否具备权限,鉴权只需1步(也就是上述的第二部),但是用的casbin后鉴权编程了两步,同样规则的维护上也增加了复杂度,那么casbin鉴权对应tp rbac那种的优势在哪里?还是我这种设计的方式存在严重的问题,因为我的思维停留在tp rbac那种设计方式上,强行结合了casbin
最后说明:首先本人不是吐槽casbin,东西几年来一直是我做后台权限向往的鉴权方式(之前一直用的fastadmin,没条件用这个),目前还是怀疑我设计的方式存在问题,希望好心人能给些建议,目前本人很痛苦(强迫症的痛苦)....

1935 2 1
2个评论

Tinywan

认证&授权概念

截图

认证&授权流程

截图

RBAC 参考

截图

  • 暂无评论
liziyu

其实也可以直接把路由菜单直接写到 casbin表中的。
user
role
resource
三张表就行了,把casbin当中间表用。

  • 暂无评论
年代过于久远,无法发表评论

864328615

420
积分
0
获赞数
0
粉丝数
2022-02-25 加入
×
🔝