phpcms中的RBAC权限系统

原文链接:https://www.cnblogs.com/duanbiaowu/p/5089243.html

PHPCMS中的RBAC权限系统主要用到了4张数据表:管理员表,角色表,菜单表,菜单权限表。先来看看数据库的数据表结构:

admin 管理员表

ID 字段 类型 Null 默认 索引 额外 注释
1 userid mediumint(6) unsigned   PK auto_increment 用户id
2 username varchar(20) YES   INDEX   用户名
3 password varchar(32) YES       密码
4 roleid smallint(5) YES 0     角色
5 encrypt varchar(6) YES       加密因子
6 lastloginip varchar(15) YES       最后登录ip
7 lastlogintime int(10) unsigned YES 0     最后登录时间
8 email varchar(40) YES       Email
9 realname varchar(50) NO       真实姓名
10 card varchar(255) NO       密保卡

admin_role 角色表

ID 字段 类型 Null 默认 索引 额外 注释
1 roleid tinyint(3) unsigned     PK auto_increment 角色id
2 rolename varchar(50) NO       角色名称
3 description text NO       描述
4 listorder smallint(5) unsigned NO 0 INDEX   排序
5 disabled tinyint(1) unsigned NO 0 INDEX   状态:1,禁用

menu 菜单表

ID 字段 类型 Null 默认 索引 额外 注释
1 id smallint(6) unsigned     PK auto_increment 菜单id
2 name char(40) NO       名称
3 parentid smallint(6) NO 0 INDEX   父id
4 m char(20) NO   INDEX   m
5 c char(20) NO   INDEX   c
6 a char(20) NO   INDEX   a
7 data char(100) NO       附件参数
8 listorder smallint(6) unsigned NO 0 INDEX   排序
9 display enum(‘1‘,‘0‘) NO 1     是否显示,1 显示

admin_role_priv 菜单权限表

ID 字段 类型 Null 默认 索引 额外 注释
1 roleid tinyint(3) unsigned   0 PK   角色id
2 m char(20) NO   INDEX   m
3 c char(20) NO   INDEX   c
4 a char(20) NO   INDEX   a
5 data char(30) NO       附件属性
6 siteid smallint(5) unsigned NO 0 INDEX   所属站点

下面来简单分析一下4张表的关系:

1.用户表中的每个用户有一个角色字段roleid,表明了该用户属于哪个角色。
2.角色表的主键为roleid,与用户表中的roleid相对应,还有角色名称,描述等,比如PHPCMS系统默认有超级管理员、总编、发布人员等角色。
3.管理员权限表中主键也是roleid,与角色表中的主键roleid相对应,表明了该角色拥有的后台操作权限。字段m、c、a分别代表的是模型 | 控制器 | 方法,因为PHPCMS本身也是MVC结构,所以更好地使权限系统的粒度细化到方法上面。
4.菜单表主要存放菜单属性,其中的m、c、a与管理员权限表中的字段相对应。

最后来看看用户的操作及验证流程:

首先,用户在后台登录,如果登录成功,将roleid(角色id)存入SESSION,然后跳转到后台首页,在PHPCMS系统中,整个后台操作的部分都在admin模块中,所以该模块中所有的控制器均继承自admin类,并且在构造方法中执行了父类的构造方法(admin的构造方法)。那么,admin类的构造方法有执行了哪些操作呢?

首先是调用自身的 check_admin() 来判断用户是否登录,紧接着判断用户的权限: check_priv()

check_priv() 方法源代码:

## 格式略微修改
final public function check_priv()
{
    if (ROUTE_M == ‘admin‘ && ROUTE_C == ‘index‘ && in_array(ROUTE_A, array(‘login‘, ‘init‘, ‘public_card‘))) {
        return true;
    }
    if ($_SESSION[‘roleid‘] == 1) {
        return true;
    }

    $siteid = param::get_cookie(‘siteid‘);
    $action = ROUTE_A;
    $privdb = pc_base::load_model(‘admin_role_priv_model‘);

    if (preg_match(‘/^public_/‘, ROUTE_A)) {
        return true;
    }
    if (preg_match(‘/^ajax_([a-z]+)_/‘, ROUTE_A, $_match)) {
        $action = $_match[1];
    }

    $r = $privdb->get_one(
        array(
            ‘m‘ => ROUTE_M,
            ‘c‘ => ROUTE_C,
            ‘a‘ => $action,
            ‘roleid‘ => $_SESSION[‘roleid‘],
            ‘siteid‘ => $siteid
        )
    );
    if (!$r) {
        showmessage(‘您没有权限操作该项‘, ‘blank‘);
    }
}

该方法首先判断当前正在进行的操作,如果是登录或者初始化操作,则退出。
然后判断角色是否为超级管理员(超级管理员默认为最高权限),如果是,依旧退出,或者如果当前方法为公开的(没有权限限制),同样退出。
最后加载 admin_role_priv_model,也就是管理员权限模型,获取当前要操作的模型 | 控制器 | 方法,利用 admin_role_priv_model 提供的方法进行查询,如果可以返回数据,则说明角色可以进行当前操作,反之,弹出提示信息:您没有权限操作该项,然后退出!

对了,忘了介绍后台菜单的生成过程啦!其实用到的还是admin类自身的方法:admin_menu(): 不过该方法是在 index.tpl.php 模板中调用的,主要进行的操作是先取出菜单表中所有菜单,然后判断当前角色,如果为超级管理员,则直接返回菜单数组,反之,则将符合当前角色权限的菜单数组返回。

原文地址:https://www.cnblogs.com/zinging/p/11739305.html

时间: 2024-11-09 14:10:42

phpcms中的RBAC权限系统的相关文章

TP支持菜单动态生成RBAC权限系统数据库结构设计方案

最简单基于RBAC权限系统数据库结构设计 包括如下几个表 1. 用户表 -- Table "t_user" DDL CREATE TABLE `t_user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(100) DEFAULT NULL, `password` varchar(100) DEFAULT NULL, `name` varchar(100) DEFAULT NULL, `status` int(11

ThinkPHP中:RBAC权限控制的实习步骤

使用版本ThinkPHP3.1.3 第一步,建表及数据 第二步,建关联模型 第三步,控制器使用关联模型.配置文件 第四步,模板显示数据 第一步,建表及数据 在数据库中,建立一个companysvn数据库,库下建立五张表 建表好导入数据的代码如下 1 # -------------------------------------------------------- 2 # Host: 127.0.0.1 3 # Server version: 5.0.45-community-nt-log 4

k8s集群中的rbac权限管理

启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,1.6 版本以上的都默认开启了RBAC查看是否开启:$ cat /etc/kubernetes/manifests/kube-apiserver.yaml spec: containers: - command: - kube-apiserver - --advertise-address=192.168.1.243 - --allow-privileged

权限系统与RBAC模型概述

为了防止无良网站的爬虫抓取文章,特此标识,转载请注明文章出处.LaplaceDemon/SJQ. http://www.cnblogs.com/shijiaqi1066/p/3793894.html 0. 前言 一年前,我负责的一个项目中需要权限管理.当时凭着自己的逻辑设计出了一套权限管理模型,基本原理与RBAC非常相似,只是过于简陋.当时google了一些权限管理的资料,从中了解到早就有了RBAC这个东西.可惜一直没狠下心来学习. 更详细的RBAC模型非常复杂.本文只做了一些基础的理论性概述.

混合了RBAC和ACL的权限系统(二) -- 基于RBAC的系统权限

http://fightplane.iteye.com/blog/1278464 1. 概念说明 A 系统级权限:从角色的角度出发,不特定于任何实际的资源的权限.比如“用户是否可以修改标题”这个权限,不针对于任何特定的标题.权限赋予给某个特定的角色.采用RBAC模型实现 B 对象级权限:从对象实例的角度出发.比如针对于某个特定的标题,编辑在这个标题上的权限.采用ACL模型实现. 那么判断用户是否可以修改某条的标题的判断顺序如下:    1) 用户所属的角色是否拥有“修改标题”的权限    2)

权限系统与RBAC模型概述[绝对经典]

0. 前言 一年前,我负责的一个项目中需要权限管理.当时凭着自己的逻辑设计出了一套权限管理模型,基本原理与RBAC非常相似,只是过于简陋.当时google了一些权限管理的资料,从中了解到早就有了RBAC这个东西.可惜一直没狠下心来学习. 更详细的RBAC模型非常复杂.本文只做了一些基础的理论性概述.本文资料完全来自互联网. 1. 权限系统与RBAC模型概述 RBAC(Role-Based Access Control )基于角色的访问控制. 在20世纪90年代期间,大量的专家学者和专门研究单位对

权限系统的设计模式 ACL RBAC ABAC

ACL(Access Control List):访问权限列表  如: user1-->AC1 user1-->AC2 user2-->AC1    此时权限汇总成一个列表 这种设计最常见的应用就是文件系统的权限设计,如微软的NTFS 对权限控制比较分散,不便于管理,比如无法简单地将一组文件设置统一的权限开放给指定的一群用户 RBAC(Role Base Access Control):基于角色的权限控制 与ACL 对比  RBAC不用给用户单个分配权限,只用指向对应的角色就会有对应的权

转:RBAC如何设计一个权限系统

前言 权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题.目前在公司负责权限这块,所以对权限这块的设计比较熟悉,公司采用微服务架构,权限系统自然就独立出来了,其他业务系统包括商品中心,订单中心,用户中心,仓库系统,小程序,多个APP等十几个系统和终端 1.权限模型 迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制(Role-Based Access Contro

实现业务系统中的用户权限管理--实现篇

在设计篇中,我们已经为大家阐述了有关权限管理系统的数据库设计,在本篇中,我们将重点放在其实现代码部分.为了让你能够更直接更有效的看到全部动作的代码,我们使用"动作分解列表"的方式来陈述每个动作以及相关资源. 实现权限管理功能的动作 动作分解 动作名 相关表名 操作集类型 (S,U,I,D,SQL) 表单 模组 字符资源 是否分页? 返回提示? 权限检测 权限初始化安装 setup 无 无 无 setup setupok 否 否 否 显示添加管理组界面 addnewgroup 无 无 a