所谓权限控制, 概念并不复杂, 就是确认某个操做是否能作, 本质上仅仅就是个bool判断.前端
权限几乎是每一个系统必不可少的功能, 和具体业务结合以后, 在系统中每每表现的很是复杂和难于控制, 很大部分缘由是把权限和具体业务结合的太过紧密, 把业务的复杂度也加入到权限控制中来了.react
一直以来, 都有个想法, 想作一套简单好用的通用权限系统, 和任何业务都没有关系, 仅仅就是权限自己的功能.
对此, 作过不少尝试, 因为设计能力有限, 最后都不了了之, 没能坚持作出来.git
直到看到了 casbin
, 这个库正是一直以来想要作的, 功能强大(几乎涵盖了全部的权限场景), 使用简单, 将权限完全的独立了出来.github
因此, 基于此库, 作了一套简单的权限系统API, 以及一个简单的前端.golang
我对 casbin
的理解是这样的, 我以为它之全部如此简洁且功能强大, 是由于它将权限分为了2块:redux
在我看来, casbin
的核心策略主要有2种:后端
用户
, 角色
, 租户
用户/角色
, 租户
, 资源
, 操做
经过对权限策略
的定义, 能够控制系统中任何资源的访问.api
组策略
的定义能够简化权限策略
的定义, 不然每一个用户
都要定义大量权限策略
ui
权限判断看似复杂, 其实就是确认能或不能的问题, 只要策略描述清楚的了权限, 这里的判断也很简单.设计
因此 casbin
的权限判断很简单, 通常只用配置文件定义下就能够了.
说白了, 它就是定义依据组策略
和权限策略
, 在什么状况下是PASS
, 什么状况是NG
我尝试基于casbin
所作的权限系统, 并非要作个大而全的, 而是针对本身的项目, 作了个基于RBAC的多租户权限系统.
API主要分3类:
组策略
和权限策略
用户
, 或者基于角色
, 或者基于租户
来表达权限关系用户
或者角色
是否有权限后端是基于 golang 来封装的: GIT地址(dev分支)
API的相关代码在: src/labrador/controllers/tenant_rbac_api
前端是简单的react+redux
应用, 主要使用了 管理
和预览
的API: GIT地址(dev分支)
用了 G6 这个库来表达权限之间的关系.
虽然只是尝试了casbin
的一部分功能, 可是依然感觉了它的简洁和强大. 它对权限的独立作了很是好的定义, 并且以库的形式提供, 也方便集成到各类业务系统中, 是个很是值得采用的通用权限库.