ThinkPHPRBAC分析笔记.docxVIP

RBAC后台技术实现 基本概念 51返利的实际需求 管理人员: 团购管理人员 订单跟踪系统人员: 另外, 具体使用每个”应用”的人员,进入各个系统后所能执行的操作范围也不同.如团购网的经理可以拥有: 浏览、添加、删除、修改、审核数据的操作, 而普通人员登录后,仅拥有浏览、添加数据的能力. 什么是”访问控制”即”权限管理”? 最本质三要素即”主谓宾”: ①Who(谁) ②How 即进行什么操作 ③Whom 被操作的对象 是否允许, 即程序要控制这个3个要素的组合是否”通过”. 或这么理解, 权限表现为一个人可以拥有哪些操作,又分别可以操作哪些对象. RBAC访问控制技术对用户的权限控制不是在用户本身上进行管理的，用户的权限是由用户所处的角色所决定的。在权限管理中，通过角色这一桥梁将用户与权限联系起来。用户和角色、角色与权限是一个多对多的关系。 Rbac的三要素 ①: 用户（User）：一个具有唯一标识符的用户，与权限相分离，只能通过所属的Role去关联权限，一个用户可以拥有多项角色； ②: 角色（Role）:一定数量的权限的集合，角色可以继承，一个角色对应多项权限； ③: 权限（Resource）：也可以看作是资源，是权限管理中执行操作和被操作对象的集合,在TP中对应着”应用”,”组”,”模块”,”方法”的访问资格和调用能力；具体参考下面的例子 相关参考: 除了基于角色的权限访问控制（Role Based Access Control，简称RBAC）外,还有自主访问控制（DAC）、强制访问控制（MAC）. DAC和MAC访问控制技术均是直接对用户本身进行权限的管理，细度太小。当用户数量庞大并且用户之间关系复杂时，主体和客体关系的匹配及权限的管理就变得复杂起来。并且权限的变更将导致权限分配列表的变更，此时可能会遭遇到很大的困难，甚至于要修改系统的源代码。 TP的Rbac角色管理操作内容 将用户加入某一组,即将用户赋予某一角色, 组可以看成是角色的同义词,这个操作的前提操作就是用户的管理,包括用户的增删改查 对角色进行控制, 在TP的Rbac中分了3个层次对角色所拥有的能力范围进行控制, 一个角色可以访问哪些”应用/组”, 访问这个”应用/组”中的哪些”模块”, 以及可以执行那些??模块”中的哪些方法. 应用授权: 一个角色可以访问哪些”应用”, 模块授权: 一个角色可以访问这个”应用”中的哪些”模块” 操作授权: 一个角色可以执行这个”应用”中的那些”模块”的哪些方法 3. 权限操作, 具体请参考下面的【3. 理解TP Rbac节点管理】 理解TP Rbac节点管理 之前理解了TP的Rbac对角色控制分3个层次, 如果需要对这个3个层次进行编辑的话,就属于节点管理. 如对某一”应用”下的某一”模块”,这个”模块”里增加新的”操作” (当然这个最新增的”操作”肯定是为了之后赋个某个角色的). 实例: 为Rbac应用下的Form模块增加新的操作:显示上传页面, 处理上传的方法. 请思考如下问题: 代码FormAction是怎么和界面上的Form模块产生对应关系的, 在FormAction中新增的方法upload_file(), upload_file_op()又是怎么被后台管理起来的? 关键步骤: Step1: 代码层中执行必要的准备工作,如果修改FormAction.class.php,增加upload_file(), upload_file_op()这个2个function的实现, 为这个2个方法分别修改add.html和新增upload_file.html模板 Step2:进入”节点管理”,点”Rbac”= 进入”Rbac”所对应的模块列表,点”Form”模块=进入”Form”模块的操作列表界面, 然后就在这个节目里增加对应的”操作项”, 一旦这些操作完成就可以在”角色管理”的”授权”操作中在”Rbac”应用的”Form”模块中看到这个2个操作条目. TP Rbac 数据库设计 ①后台账号（用户戒者管理员）表 think_user ②角色分组表 think_role ③用户角色关系表 think_role_user ④系统节点表 think_node think_note 其实就是记录下了整个网站操作对应的 项目名称 模块名称 和 操作名称。 字段name就是当项目，模块或者操作的名称了。 字段pid 记录他们的从属关系，比如某一个模块是属于哪个项目，某个操作属于哪个模块。 字段level 表示该节点的层级 换句话就是说 level=1 为项目 ,level=2为模块 ,level=3就是操作了，比如说 admin项目，他的pid就是 0 (项目的PID都是0) level就是1,nane就是ad