casdoor casbin 使用过程记录

casbin 文档中有的就不做赘述，这里记录的是文档中没有的，或者自己学习时忽略的。

在定义模型时 request_definition 中的三元组是一个经典的场景，但是并不限于三元组，还可以有更多的元组，比如增加一个域：

[request_definition]
r = sub, dom, obj, act

实际上在 policy_effect 中定义最终是否授权的求值公式时，其中用到的 p.eft 是在策略文件中就已经定义了的，

p, alice, data1, read, allow
p, alice, data1, read, deny

最后的 allow 和 deny 就是 p.eft 的值，默认 allow ，默认不显示。

policy_effect 是为了应付复杂的授权场景准备的，实际的项目中，可能会因为以下原因产生授权 p.eft 冲突的情况：

• 角色继承：在使用角色的继承机制时，一个用户可能同时拥有多个角色，这些角色对同一个资源有不同的权限。
• 分层策略：在企业或组织的权限管理中，可能会有高层次的默认策略和针对特定情况的例外策略。
• 动态规则更改：运行中的系统可能允许管理员动态更改规则，有时可能在不完全理解现有规则的情况下添加新规则。
• 组合策略：当策略是由多个因素组合而成时（如用户、时间、位置等），可能会因为组合的复杂性而产生冲突。
• 遗留规则：随着时间的推移，旧的权限可能还在系统中，但没有得到适当的更新或删除。
• 细粒度控制：在需要非常细粒度控制的系统中，也许会有很多针对特定条件的规则。

当策略规则的 p.eft 冲突时，会用到 policy_effect 中定义的公式来计算最后的授权结果。

匹配器 matchers 的 m 值是通过一些逻辑运算计算得来的，这些逻辑运算可以非常复杂，当最后的 m 值为真时，就会有一条匹配到的策略规则，最后这些匹配到的策略规则就会使用 policy_effect 求值最后是否授权。

role_definition 是定义角色关系的部分， g = _, _ 其中的 _ 是占位符，用来检查第一个参数是否是第二个参数的角色成员，也就是角色继承的关系。但是Casbin实际上支持可变参数的角色继承函数，也就是说g函数可以有更多的参数，例如 g(_, _, _) 或者更多（受版本影响，读文档了解）。

模型文件一旦设定就不会再被更改，所以 casbin 没有提供修改模型的 API ，策略文件中会存入具体的信息，例如主体，资源，动作，域，租户，有可能在应用中被修改，所以 casbin 提供了一些 API 用于修改。

添加permission配置

添加配置 permission 时，选自己的组织，会一直报错。

• 原因： 点击 添加 就会立刻在数据库写入一条记录，并且默认属于内置的 build-in 组织，而 名称 是唯一的ID字符串，这个时候如果把一些需要填入的项目都填入以后点击 保存 ，就会报错，实际上问题出在写入数据库的顺序上，如果等到填完信息，点提交再写库，就不会有问题，现在先写了库，库里就有了默认的一个随机的字符串 名称 ，如果这个时候修改了项，就会提示没有找到这个记录，因为确实没有了这个记录。

• 解决办法： 需要先修改一下 组织 ，保存并退出，然后再点 编辑 进去，现在把项目填入再点保存就不会报错了。

sdk.getUser(id)

这个方法的坑在于其参数 id ，实际上这里需要的值是指向数据库中的 name 字段，而不是 id 字段。

在 casdoor 中间件中，通过 token 解析出的用户，是在创建 token 时的用户，如果用户信息比如用户名 name 发生了改变，这时候要想通过此方法使用 name 参数取到用户信息也是不可能的。