所謂權限控制, 概念並不複雜, 就是確認某個操做是否能作, 本質上僅僅就是個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
的一部分功能, 可是依然感覺了它的簡潔和強大. 它對權限的獨立作了很是好的定義, 並且以庫的形式提供, 也方便集成到各類業務系統中, 是個很是值得采用的通用權限庫.