學習 casbin 的最大攔路虎就是他的兩個配置文件，很多新手完全是蒙圈的。

這里我們以本地化權限控制為例，不直接上數(shù)據(jù)庫化的，便于大家調(diào)試理解。

我們在使用 casbin 時需要用到兩個配置文件，分別是 model.conf 和 policy.csv。

他們分別記錄了，權限匹配規(guī)則也叫模型定義文件 model.conf ，以及權限列表也叫策略文件 policy.csv。

一、模型定義文件 model.conf

[request_definition] 
r = sub, obj, act 
 
[policy_definition] 
p = sub, obj, act 
 
[role_definition] 
g = _, _ 
 
[policy_effect] 
e = some(where (p.eft == allow)) 
 
[matchers] 
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act 

簡單解釋下這些定義的意義：

[request_definition]

這是關于請求的一些定義，分別定義了：

訪問實體 (Subject)，訪問資源 (Object) 和訪問方法 (Action)

這個很好理解：我們一般描述一條請求大都會這么描述：

哪個用戶用啥方法請求了某個資源

這里的：

哪個用戶→就是 實體 (Subject)

啥方法→就是 訪問方法 (Action)

某個資源 → 訪問資源 (Object)

比如：admin 用戶使用 GET 方法訪問 /user/list 接口

[policy_definition]

這是是對策略的定義。

我們還有一個配置文件 policy.csv ，這里就是約束里面定義些什么字段。

我們一般描述一個權限是這樣的：

誰擁有對某個資源的啥權限

這里的：

誰→就是 實體 (Subject)

啥權限→就是 訪問方法 (Action)

某個資源 → 訪問資源 (Object)

比如：admin 組擁有 /user/list 接口的 GET 權限

[policy_effect]

這是對策略的定義。

我們在 request_definition 和 policy_definition 定義的這些資源，怎么去匹配。

不同的需求可以寫成不同的方式，這里我們寫成 RBAC 權限控制的經(jīng)典方案:

e = some(where (p.eft == allow)) 

p.eft 代表決策結(jié)果。

其意思就是：如果存在一個匹配的策略規(guī)則就通過。

[role_definition]

這是角色的定義。

_, _ 表示角色繼承關系的前項和后項，即前項繼承后項角色的權限。

就像 編輯 權限只有對文章的讀寫權限，管理員擁有 編輯 的全部權限，這種繼承關系。

[matchers]

請求和策略的匹配規(guī)則。

先來解釋下：

r.obj == p.obj && r.act == p.act 

這段就是在匹配的時候，請求傳過來的 obj 和 我們策略組里面的 obj 要匹配到，同樣是 act 也是同樣。

最后來解釋：

g(r.sub, p.sub) 

g 所關聯(lián)的是角色定義，所以他要滿足我們的前項繼承后項角色的權限。

二、策略文件 policy.csv

p, member, /depts, GET 
p, member, /depts/:id, GET 
 
p, admin, /depts, POST 
p, admin, /depts/:id, PUT 
p, admin, /depts/:id, DELETE 
 
g, admin, member 
g, super, admin 
g, lili, member 

一看到 .csv 文件，就應該能想到，他是一種特殊的文件，我們很多從數(shù)據(jù)庫里面導出數(shù)據(jù)就會導出這個格式的文件。

所以這部分的內(nèi)容后期也可以從數(shù)據(jù)庫里面去讀取。

這個文件很好理解，結(jié)合上一個模型文件：

p 是定義資源的策略的

簡而言之：誰擁有對某個資源的啥權限

g 是定義權限組的

簡而言之：誰繼承誰的權限