beego利用casbin进行权限管理——第一节 起步、测试

beego利用casbin进行权限管理——第一节 起步、测试

beego利用casbin进行权限管理——第二节 策略存储

beego利用casbin进行权限管理——第三节 策略查询

beego利用casbin进行权限管理——第四节 策略更新

beego利用casbin进行权限管理——第五节 策略更新（续）

EngineerCMS工程师知识（资料）管理系统的github地址。该系统正是充分利用了casbin进行树状目录赋权。

casbin很好用，支持beego等框架，作者很勤奋，把几乎所有的框架都写了adapter适配器。

补充：经过这么久的使用，我觉得为何要用这个东西，总结有这么几个：

1.用了casbin后，我们自己的项目启动的时候，会读取权限数据库到内存（map），这期间的查询会只是查询内存，不用查数据库。权限的存储和修改，casbin先改内存，然后同步修改数据库。如果自己写，还是比较麻烦的。

2.它设计好了策略逻辑，不用自己操太多心。比如，用户user1属于一个角色role1，用户user1具有一个资源data1的某个权限action1，role1也具有另一个资源data2的某个权限action2，那么这个user1就同时具备了data1的action1和data2的action2，这是自动在casbin的规则中定义就行了。

3.总的来说还是节约了代码，增删查改都是一行代码搞定。比如下面：

// o := orm.NewOrm()
		// qs := o.QueryTable("casbin_rule")
		// _, err = qs.Filter("PType", "p").Filter("v1", "/onlyoffice/"+strconv.FormatInt(w.Id, 10)).All(&users)
		// if err != nil {
		// 	beego.Error(err)
		// }
		users := e.GetFilteredPolicy(1, "/onlyoffice/"+strconv.FormatInt(w.Id, 10))//这一行代替了上面

拿过来试了一下，先记录如下：

1、我的权限设计思路类似hauth是：a)用户；b)角色；c)权限；d)资源放在树状目录下，数据库记录的是目录的id，而非具体的路径。向用户分配角色，再将权限分配给角色。

2、casbin中下载beego-orm-adapter，并修改一点代码：

3、beego项目中conf目录下拷入rbac_model.conf；建立一个rolecontrollers.go，其中代码来自beego-orm-adapter中的readme.md，如下图：

4、bee run就会新建一个casbin_rule的数据库，填入策略数据如下图：

5、可以建个路由访问test()测试一下了：

问题：用户访问的资源比如是/v1/v2/v3/data.jpg，而数据库中所保存的资源data.jpg的路径不是明确的，只是保存了它所属的目录v3的id——目录v3的数据库也只保存了它父级v2的id……（也就是说/v1/v2/v3/data.jpg中的v1随时可能改名成v4，然后整个资源路径就变成/v4/v2/v3/data.jpg ）所以策略要用保存id来实现。

先到这了。