RBAC -》 权限管理

RBAC:Role Based Access Control:基于角色的访问控制 需求:

1. 权限、角色、管理员

2   权限管理【无限级】

注意:权限会被分配给角色,不是管理员!

3 角色列表

添加角色时要给角色分配权限:

4

管理员列表

5    系统中默认有一个超级管理员并且不能被删除【无法分配权限,拥有所有的权限】

6    只有登录了才能进行后台

7    后台左侧只显示当前管理员有权限访问的按钮

实际操作:

  1. 建表

三个主表两个中间表:

/************RBAC权限表***********/

drop table if exists p40_privilege;
create table p40_privilege
(
id mediumint unsigned not null auto_increment comment ‘Id‘,
pri_name varchar(30) not null comment ‘权限名称‘,
module_name varchar(30) not null default ‘‘ comment ‘模块名称‘,
controller_name varchar(30) not null default ‘‘ comment ‘控制器名称‘,
action_name varchar(30) not null default ‘‘ comment ‘方法名称‘,
parent_id mediumint unsigned not null default ‘0‘ comment ‘上级权限Id‘,
primary key(id)
)engine =InnoDB default charset=utf8 comment ‘权限‘;

drop table if exists p40_role_pri;
create table p40_role_pri
(
pri_id mediumint unsigned not null comment ‘权限id‘,
role_id mediumint unsigned not null comment ‘角色id‘,
key pri_id(pri_id),
key role_id(role_id)
)engine=InnoDB default charset=utf8 comment ‘角色权限‘;

drop table if exists p40_role;
create table p40_role
(
id mediumint unsigned not null auto_increment comment ‘id‘,
role_name varchar(30) not null comment ‘角色名称‘,
primary key(id)

)engine=InnoDB default charset utf8 comment ‘角色‘;

drop table if exists p40_admin_role;
create table p40_admin_role
(
admin_id mediumint unsigned not null comment ‘管理员id‘,
role_id mediumint unsigned not null comment ‘角色id‘,
key admin_id(admin_id),
key role_id(role_id)
)engine =InnoDB default charset=utf8 comment ‘管理员角色‘;

drop table if exists p40_admin;
create table p40_admin
(
id mediumint unsigned not null auto_increment comment ‘id‘,
username varchar(30) not null comment ‘用户名‘,
password char(32) not null comment ‘密码‘,
primary key(id)
)engine=InnoDB default charset utf8 comment ‘管理员‘;

insert into p40_admin(username,password) values(‘admin‘,md5(‘admin‘));

说明:TP框架中自带一个RBAC的类:也是要使用五张表,TP只提供了五个表和一个类,这个类只提供了将来对五个表的查询,但是这五个表的操作还需要我们自己写!不需要使用TP的,因为它就没有提供什么东西,还是需要自己写。

2  使用GII直接生成三个主表的代码,表间关系的代码需要我们自己添加完成!!

生成权限列表:

修改配置文件:

设置为生成递归的代码

‘tableName‘ => ‘p40_privilege‘, // 表名
‘tableCnName‘ => ‘权限‘, // 表的中文名
‘moduleName‘ => ‘Admin‘, // 代码生成到的模块
‘withPrivilege‘ => FALSE, // 是否生成相应权限的数据
‘topPriName‘ => ‘‘, // 顶级权限的名称
‘digui‘ => 1, // 是否无限级(递归)
‘diguiName‘ => ‘pri_name‘, // 递归时用来显示的字段的名字,如cat_name(分类名称)
‘pk‘ => ‘id‘, // 表中主键字段名称
/********************* 要生成的模型文件中的代码 ******************************/
// 添加时允许接收的表单中的字段
‘insertFields‘ => "array(‘pri_name‘,‘module_name‘,‘controller_name‘,‘action_name‘,‘parent_id‘)",
// 修改时允许接收的表单中的字段
‘updateFields‘ => "array(‘id‘,‘pri_name‘,‘module_name‘,‘controller_name‘,‘action_name‘,‘parent_id‘)",
‘validate‘ => "

去掉搜索

/**************** 搜索字段的配置 **********************/
‘search‘ => array(),

生成代码:

p40_privilege.php

到此无限级权限完成!

2.2. 再生成管理和角色

修改管理员管理的功能

  1. 管理员密码加密  在admin模型添加

// 添加前
protected function _before_insert(&$data, $option)
{
$data[‘password‘]=md5($data[‘password‘]);
}

  1. 超级管理员不能被删除

// 删除前
protected function _before_delete($option)
{
if($option($option[‘where‘][‘id‘]) == 1 )
{
$this->error = ‘超级管理员无法删除‘;
return FALSE;
}
}

超级管理员不显示删除按钮

<td align="center">
<a href="<?php echo U(‘edit?id=‘.$v[‘id‘].‘&p=‘.I(‘get.p‘)); ?>" title="编辑">编辑</a>
<?php if($v[‘id‘] >1) : ?>
|
<a href="<?php echo U(‘delete?id=‘.$v[‘id‘].‘&p=‘.I(‘get.p‘)); ?>" onclick="return confirm(‘确定要删除吗?‘);" title="移除">移除</a>

<?php endif; ?>
</td>

  1. 修改管理员时,如果密码留空就不修改密码

3.1 修改表单验证规则,修改时可以为空,添加时不能为空

array(‘username‘, ‘require‘, ‘用户名不能为空!‘, 1, ‘regex‘, 3),
array(‘username‘, ‘1,30‘, ‘用户名的值最长不能超过 30 个字符!‘, 1, ‘length‘, 3),
//第6个参数:规则什么时候生效:1 添加时生效 2 修改时生效 3 所有情况都生效
array(‘password‘, ‘require‘, ‘密码不能为空!‘, 1, ‘regex‘,1),

现在可以不填写密码了,但是被修改为空:

修改之前判断一下即可:

// 修改前
protected function _before_update(&$data, $option)
{
if($data[‘password‘])
$data[‘password‘]=md5($data[‘password‘]);
else
unset($data[‘password‘]);
}

权限和角色的关系的代码

用到的表:

实际操作:

  1. 在添加角色的表单中制作权限列表

//取出所有的权限
$priModel=D(‘privilege‘);
$priData=$priModel->getTree();

// 设置页面中的信息
$this->assign(array(
‘priData‘=>$priData,
‘_page_title‘ => ‘添加角色‘,
‘_page_btn_name‘ => ‘角色列表‘,
‘_page_btn_link‘ => U(‘lst‘),
));

  1. 在表单中循环输出
  1. 提交表单之后循环选中的每个权限插入到角色权限中间表中

修改角色模型在添加之后:

public function _after_insert($data,$opiton)
{
$priId=I(‘post.pri_id‘);
$rpModel=D(‘role_pri‘);
foeach($priId as $v)
{
$rpModel->add(array(
‘pri_id‘=>$v,
‘role_id‘=>$data[‘id‘],
));
}
}

  1. 在角色列表中,再添加一列列出这个角色所拥有的所有的权限名称

修改角色模型中的search方法

$data[‘data‘] = $this->alias(‘a‘)
->field(‘a.*,c.pri_name‘)
->join(‘left join __ROLE_PRI__ b on a.id = b.role_id
left join __PRIVILEGE__ c on b.pri_id=c.id‘)
->where($where)
->limit($page->firstRow.‘,‘.$page->listRows)
->select();
return $data;

时间: 2024-10-20 01:58:49

RBAC -》 权限管理的相关文章

RBAC权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限. 这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接

使用SpringSecurity3实现RBAC权限管理

1. What? 什么是权限管理? 具体可参见百度:http://baike.baidu.com/view/2108713.htm 名词备注: 数据级权限:百科内的权限管理一文解释的比较不错,但其中的"数据级权限"有的人看来会觉得有点摸不着头脑.数据级权限,即表示权限与特定数据有联系的权限,比方说,某用户只能创建100个用户.这个100,就是数据级权限的一个指标. 2. How?怎么样实现权限管理? 2.1.一种烦恼 也许很多程序员会在权限管理中遇到这样的一个问题. 大部分项目都需要权

基于RBAC权限管理模型学习

在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限.这就极大地简化了权限的管理. 在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色.角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收. 角色与角色的关系可以建立起来以囊括更广泛的客观情况. BAC支持三个著名的安全原则:最小权限原则,责任分离原则和数据抽象原则. (1)最小权限原则之所以被RBAC所支持,是因

vue基于d2-admin的RBAC权限管理解决方案

前两篇关于vue权限路由文章的填坑,说了一堆理论,是时候操作一波了. vue权限路由实现方式总结 vue权限路由实现方式总结二 选择d2-admin是因为element-ui的相关开源项目里,d2-admin的结构和代码是让我感到最舒服的,而且基于d2-admin实现RBAC权限管理也很方便,对d2-admin没有大的侵入性的改动. 预览地址 Github 相关概念 不了解RBAC,可以看这里企业管理系统前后端分离架构设计 系列一 权限模型篇 实现了RBAC模型权限控制 菜单与路由独立管理,完全

ThinkPHP RBAC权限管理机制

RBAC是ThinkPHP很好用的后台权限管理的,话不多说,实现方法如下,也方便以后自己查询使用: 1.新建4个数据库表 self_role权限表 CREATE TABLE `self_role` ( `id` smallint(6) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL, `pid` smallint(6) DEFAULT NULL, `status` tinyint(1) unsigned DEFAULT

基于RBAC权限管理

一般web系统操作人员多时都会需求权限管理,一来限制操作范围,二来限制数据公开度. 现在最流行的一个模式为 RBAC (Role-Based Access Control) 基于角色的访问控制.设定权限范围定义到角色中,然后再分配到每个用户. 这里仅以一般后台管理系统为例,叙说数据结构: 需求: 菜单需要针对不同部门使用不同的菜单结构. 权限项能精确到页面中某个内容或局部功能. 基本要求:没有权限的菜单,页面中内容或链接禁止显示. 表结构 CREATE TABLE `power_item` (

【转】RBAC权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接将

Yii2-admin RBAC权限管理的实现

yii2-admin是yii2 rbac的一套管理工具,实现了漂亮的界面和完整的权限管理功能,不用自己再去写权限代码了,使用之前请将yii2的源码更新到最新版本. git源码地址:https://github.com/mdmsoft/yii2-admin 安装yii2-admin: 1.首先切换到项目目录下 2.执行该语句:composer.phar require mdmsoft/yii2-admin 注:如果提示could not open input file composer.phar

基于Django实现RBAC权限管理

概述 RBAC(Role-Based Access Control,基于角色的访问控制),通过角色绑定权限,然后给用户划分角色.在web应用中,可以将权限理解为url,一个权限对应一个url. 在实际应用中,url是依附在菜单下的,比如一个简单的生产企业管理系统,菜单可以大致分为以下几块:制造.资材.生产管理.人事.财务等等.每个菜单下又可以有子菜单,但最终都会指向一个url,点击这个url,通过Django路由系统执行一个视图函数,来完成某种操作.这里,制造部的员工登录系统后,肯定不能点击财务

thinkPHP的RBAC权限管理

thinkphp自带一个权限类:RBAC.class.php,里面有生成表的create table语句,也就是它的数据库设计,还有一些方法,比如getAccessList(),可以根据管理员ID号获得权限节点. 1.涉及到的表有五个,为了方便理解,可以总结为: 用户表(user):顾名思义,就是用户了,比如admin.张三.李四.王五 角色表(role):顾名思义,就是定义好的角色,比如财务管理员.文章管理员.产品管理员 用户角色关系表(user_role):顾名思义,就是将用户和角色对应起来