面试官:说说Casbin配置文件里的设计哲学(配置详解)
学习 casbin 的面试最大拦路虎就是他的两个配置文件,很多新手完全是官说蒙圈的。
这里我们以本地化权限控制为例,置文置详不直接上数据库化的计哲解,便于大家调试理解。学配
我们在使用 casbin 时需要用到两个配置文件,面试分别是官说 model.conf 和 policy.csv。
他们分别记录了,置文置详权限匹配规则也叫模型定义文件 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 权限控制的经典方案:
e = some(where (p.eft == allow))
p.eft 代表决策结果。
其意思就是:如果存在一个匹配的策略规则就通过。
[role_definition]
这是角色的定义。
_, _ 表示角色继承关系的前项和后项,即前项继承后项角色的权限。
就像 编辑 权限只有对文章的读写权限,管理员拥有 编辑 的全部权限,这种继承关系。
[matchers]
请求和策略的网站模板匹配规则。
先来解释下:
r.obj == p.obj && r.act == p.act
这段就是在匹配的时候,请求传过来的 obj 和 我们策略组里面的 obj 要匹配到,同样是 act 也是同样。
最后来解释:
g(r.sub, p.sub)
g 所关联的是角色定义,所以他要满足我们的前项继承后项角色的权限。
二、策略文件 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 文件,就应该能想到,他是一种特殊的文件,我们很多从数据库里面导出数据就会导出这个格式的文件。
所以这部分的内容后期也可以从数据库里面去读取。
这个文件很好理解,结合上一个模型文件:
p 是定义资源的策略的
简而言之:谁拥有对某个资源的啥权限
g 是定义权限组的站群服务器
简而言之:谁继承谁的权限