Thinkphp 3.2.3 Rbac研究

Thinkphp 3.2.3 Rbac研究

1.旧版的资料

ThinkPHP中关于RBAC使用详解

http://www.lyblog.net/detail/552.html

 

 

这是一篇很好的文章，但讲的是老版的thinkphp，新版发生了很多变化。

2.树林的节点路径授权、节点集合授权及节点孤点授权

详见ppt

Thinkphp中Rabc的授权模式采用的是节点路径授权

3.RBAC只能作为模型原型为网站建设做概念指导，如果真用就非常坑。

a) 运行效率低的感人

i. 查询的sql语句都是随便的四表连用。而且这样的查询语句还在3重for循环中使用。如此感人的效率让我对tp的效率深深的质疑。

ii. 当网站规模稍大时资源开销简直惊人

1. 采用session方式：就是把用户能够访问的[模块][控制器][方法]树写入session中， 如果网站功能复杂有上千个方法，那么每个用户的session中仅授权一项就上兆。

2. 采用实时模式那么前面的四连表三循环查询每个页面要用一次

iii. 

b) 没有足够的文档各种坑多的感人

i. 很多限制，都在细节中，没有文档只能细细研究代码

ii. 代码中大量的使用了自定义常量，这些常量没有注释文档，还得通过源代码判断具体作用

iii. 代码很明显经过多版本的变革，难读而且容易误解，必须测试后才能确定

1. 代码关于模块modules/app控制器controller的使用显然由于不同版本的变化弄的乱七八糟。不从头读代码很容易乱。

iv. 不同版本的具体编写格式都有略微差别，而这些差别会导致要命的错误

c) Rbac仅有一点点内核，要补的代码太多而且要对接的细节太多

i. 没有足够的文档和代码注释更放大了这个缺点

ii. Controller又判断是否为public，然既无文档，却仅有一行注释，可是变量用的却是$modules。

iii. 最终能用下来基本需要完全的分析Rbac的每一行代码

d) 代码本身有很多不足bug（虽然代码本意力求完美）

i. 例如不需要认证的模块完全靠用户自己实现而rbac又企图留下一些很不完善的公共标注，其中大量的常量要自己定义并且自己编写程序来应用他们。

ii. Role搞了个pid也就是继承，然而仅仅能继承一级。而且pid不能为0而建站语句中role表又没有AUTO_INCREMENT=1

e) Rabc类的授权仅仅是thinkphp中的每个方法和用户两者的匹配授权，无法作用与更复杂的授权匹配。

i. 其实使用tp框架这个一般够用

1. 多个不同个功能使用多个方法编写

2. 即使有同个方法的不同授权可以用其他空方法跳转的方式来做授权检查

ii. 但如果要实现好友之间的授权还是很难的

1. 因为好友间授权不能用role层来实现

2. 好友间授权用好友登录来实现

3. 这种授权，不是方法对角色的授权，而是数据对数据的授权。

4. 这种数据对数据的授权，是tpRbac实现不了的

f) 自己的代码和原本不完善的架构很难配合，出各种各样的问题简直家常便饭

 

总得来说Thinkphp的Rbac更适合学习而不是实用。了解授权的基本原型，和调试，读代码，修bug的能力。

4.RBAC中的关键语句

function AccessDecision($appName=MODULE_NAME) {

isset($accessList[strtoupper($appName)][strtoupper(CONTROLLER_NAME)][strtoupper(ACTION_NAME)])

}

即：isset($accessList[MODULE_NAME][CONTROLLER_NAME][ACTION_NAME]);

$accessList是模式1中存入session中的 ["_ACCESS_LIST"]授权树数组，或者模式2中从数据库中查询得来的授权树数组。

5.总结

真正需要用户授权的网站基本不会用如此粗糙的模型，该模型仅仅适合学习和明明没必要搞rabc却非要搞的小网站。