thinkphp的RBAC实现一直没弄明白怎么做。感觉很复杂。其实自己也可以diy一套自己的rbac吧，也许更容易理解和使用。

  以下是我的一些想法。

  1.权限数据的存储

  我的选择：独立配置一个access.php文件。

  理由：通常RBAC数据都是存在数据库中的。不过有这个必要吗？存在数据库，使用的时候还是要缓存出来提高使用效率，那为什么不直接存在配置文件中呢？特别是thinkphp1.6RC1配置扩展的功能，大大方便了调用。

   2.何处检测权限

  我的选择：设置一个基类BaseAction，在它初始化方法中检测权限。

  理由：合理利用基类，可以大大减少代码，这个本来就是必须的利用的。那么可以顺便就在初始化的时候实现这个功能。

  3.如何检测权限

  我的选择：通过MODULE_NAME和ACTION_NAME两个变量，在access.php中查询权限

  理由：MODULE_NAME和ACTION_NAME是App对象运行中得到的两个变量，因此整个环境中都能得到这两个值。其中MODULE_NAME值为调用的Action的名字（例如,名为IndexAction，则MODULE_NAME为Index，ACTION_NAME类似），ACTION_NAME值为调用的方法名。称。那么，通过合理化组织的access.php，可以查询到对应模块对应方法的权限。

  4.access.php的写法（待完善）

  a.键值对的选择

  考虑到对于一个工程，Action的数量也许变动较多，而UserGroup变动相对较少，就更改方便来说，键取Action，值对应相对的UserGroup比较好。

  同时，考虑到调用方便，键我采用的是MODULE_MANE.'_'ACTION_NAME的方式命名。

  例如：

'Index_index'=>'*', 
'Index_login'=>'none',

  (这样呢

'Index'=>array(  'index'=>'*',  
                 'login'=>'none' 
              ) 

这样的好处是，一个Action的放在一个键下面，修改也许方便点。待考虑。）

b.值的命名

  *                      任何人都可以访问

  none                 仅仅未登陆用户可以访问

 notallow:            考虑到UserGroup的扩展性，这个可能是有用的。例如

'Article_read'=>'notallow:none',//禁止匿名用户访问 

 fun:                   调用自定义函数，放在最后。例如

'Article_update'=>'admin,fun:is_writer',//管理员和作者可以修改文章 

   要求：所有验证函数都要接受一个数组变量，返回true或者false返回是否具有权限