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来实现。

先到这了。


版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/hotqin888/article/details/78460385