# 账号密码
USERNAME=mongodb账号
PASSWORD=mongodb密码

# url
URL=你的域名

# db
DB=db里的库

# db url
DATABASE_URL=mongodb://${USERNAME}:${PASSWORD}@${URL}:27017,${URL}:27018,${URL}:27019/${DB}?replicaSet=rs0&authSource=admin

# redis url
REDIS_USERNAME=redis用户名
REDIS_PASSWORD=redis密码
REDIS_IP=你的ip:端口
REDIS_URL=redis://:${REDIS_PASSWORD}@${REDIS_IP}/0

# github
# github申请oauth2.0 流程
# doc：https://docs.github.com/cn/developers/apps/building-oauth-apps/creating-an-oauth-app
GITHUB_CLIENT_ID=github client id
GITHUB_CLIENT_SECRET=密钥

# 请求的定义
# r: request缩写
# sub: subject 主题(可以是角色名 or 用户名，一般都是用户名)
# obj: object (目标对象，一般是一个请求路径：/v1/test)
# act：行为(增删改查，对应RESTFUL就是POST、DELETE、PUT、GET)
# eft: 允许不填，默认为allow
# 官方文档：https://casbin.io/zh/docs/syntax-for-models#request%E5%AE%9A%E4%B9%89
[request_definition]
r = sub, obj, act

# 策略的定义
# 这里与request定义一致
# 定义这个是为了下面的`effect、matchers`与`policy.csv`文件的字段一一对应
# 官方文档：https://casbin.io/zh/docs/syntax-for-models#policy%E5%AE%9A%E4%B9%89
[policy_definition]
p = sub, obj, act

# 策略作用：这个就比较有意思了
# 参考官方文档：https://casbin.io/zh/docs/syntax-for-models#policy-effect%E5%AE%9A%E4%B9%89
[policy_effect]
e = some(where (p.eft == allow))
# 含义：存在任意一个决策结果为allow的匹配规则，则结果为true
# e = !some(where (p.eft == deny))
# 含义：不存在任何为deny的结果就通过，返回true

# 匹配器
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
# 这里开始结合policy文件讲比较好

# model.conf
[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

# policy.csv
# 策略，xiaoqinvar用户，/test接口，GET方法，允许访问(默认allow)
p, xiaoqinvar, /test, GET
# 策略，rabbit用户，/test接口，POST方法，允许访问(默认allow)
p, rabbit, /test, POST

# 请求
xiaoqinvar, /test, GET # true
xiaoqinvar, /test, POST # false
rabbit, /test, GET # false
rabbit, /test, POST # true

// jwt 认证后的用户对象
const subject = ctx.state.user;
// 请求的资源，即http://localhost:7001/test
// 这里就是/test，底层与koa用法一致 `ctx.path`
const object = ctx.path;
// 这里不用多说就是 GET、...、DELETE请求方法
const effect = ctx.method;

// 鉴权
// 与上面对应(先大致理解)
// subject: xiaoqinvar
// object: /test
// effect: GET
// 那么，xiaoqinvar, /test, GET即xiaoqinvar这个用户就允许访问，因为上面的策略文件里面有给予他这个权限
const auth1 = await this.enforcer.enforce(subject, object, effect);

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub) && g2(r.obj, p.obj) && r.act == p.act

# 允许管理员访问 /user下的所有方法
p, MANAGER, userGetApi, GET
p, MANAGER, userPostApi, POST
p, MANAGER, userPutApi, PUT
p, MANAGER, userDeleteApi, DELETE

# 只允许用户访问 /user GET请求
p, USER, userGetApi, GET

# 用户、用户角色
g, xiaoqinvar, MANAGER
g, ant, USER

# /user接口的各GET... DELETE方法，接口 接口角色
g2, /user, userGetApi
g2, /user, userPostApi
g2, /user, userPutApi
g2, /user, userDeleteApi

xiaoqinvar, /user, GET # true
xiaoqinvar, /user, DELETE # true

ant, /user, GET # true, 下面都是false
ant, /user, POST
ant, /user, PUT
ant, /user, DELETE

[request_definition]
#   用户名，api，方法
r = sub, obj, act
#   用户名，api，方法，允许/拒绝
r2 = sub, obj, act, eft

[policy_definition]
p = sub, obj, act
# ABAC就不一样了，这里策略的sub_rule相当于一段判断条件表达式，就这一个区别，可以看看策略文件
# obj,...,eft 与之前的一致
p2= sub_rule, obj, act, eft

[role_definition]
# 用户继承(g, xiaoqinvar, MANAGER) -> xiaoqinvar 拥有 MANAGER角色
g = _, _
# 资源集成(g2, /user/info, testApiGet) -> /user/info 属于 testApiGet资源组
g2 = _, _

[policy_effect]
# e 默认条件 -> 只要有一个条件满足了就通过
e = some(where (p.eft == allow))
# e2 自定义条件 -> 只要没有否定条件就通过，也就是说e2条件下，在策略文件中没有写任何策略，也判定为通过，因为！没有deny策略即通过！
e2 = !some(where (p.eft == deny))

[matchers]
#RABC
# 这里我请求是个对象
# 请求对象中的username要和策略文件中的一致
# 如果请求对象中的role角色为'root'则不用查策略文件，全部通过
m = g(r.sub.username, p.sub) && g2(r.obj, p.obj) && r.act == p.act || r.sub.role == 'root'
#ABAC
m2 = eval(p2.sub_rule) && r2.obj == p2.obj && r2.act == p2.act && p2.eft == 'allow' || r.sub.role == 'root'