从零开始码后台管理系统——权限表设计

MSSQL的库

设计表：

Users 用户表 字段：userid,username,userpermission

Roles 角色表 字段：roleid,rolename,rolepermission

UserInRole 用户角色对应表 字段：userid,roleid

PermissionList 权限列表 字段：permissionid,permissionDescription,permissionGroup

权限设计：许可、禁止和未设置三种状态,Allow,Deny,Not Set

目标：

实现用户权限的定义。

首先定义角色权限，用户与角色间是多对多的关系。用户权限继承自角色权限。

情况一：用户所属的多个角色存在权限冲突时，取最小权限，即某权限角色A许可，角色B禁止，则该权限为禁止。

情况二：用户所属的角色均未对某权限进行设置时，即NotSet状态，则该权限同DENY

情况三：用户所属的角色对某权限为许可时，也可单独设置该权限为禁止。

功能：

设置用户权限：

默认情况下，用户权限继承自所属角色的权限

可单独设置某用户的权限

扩展权限

权限定义可随时增加，并可以分组。当增加权限时，默认的角色权限均为未设置状态

问题：

1、在MSSQL数据库中如何设置userpermission和rolepermission字段的字段类型？

2、如何存取用户权限？特别是当用户属于多个角色时，如何高效的设置用户权限的问题

网站专用制作，价格绝对优惠，不做网站也可以交流一下经验……

要做网站的加我122216605/541597237。

绝对让你的网站给浏览者最COOL的冲击……

权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。

迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制（Role-Based Access Control)

RBAC-0模型是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。

用户 是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户,可以是OA系统的内部员工,也可以是面向C端的用户,比如阿里云的用户。

角色 起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。

有人会问了为什么用户不直接关联权限呢？在用户基数小的系统,比如20个人的小系统，管理员可以直接把用户和权限关联，工作量并不大，选择一个用户勾选下需要的权限就完事了。

但是在实际企业系统中，用户基数比较大,其中很多人的权限都是一样的，就是个普通访问权限，如果管理员给100人甚至更多授权,工作量巨大。

这就引入了 "角色(Role)" 概念,一个角色可以与多个用户关联,管理员只需要把该角色赋予用户,那么用户就有了该角色下的所有权限,这样设计既提升了效率,也有很大的拓展性。

权限 是用户可以访问的资源,包括页面权限,操作权限,数据权限:

以上是RBAC的核心设计及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面介绍这三种类型

此模型引入了角色继承(Hierarchical Role)概念，即角色具有上下级的关系，角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

基于核心模型的基础上，进行了角色的约束控制，RBAC2模型中添加了责任分离关系。

其规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。主要包括以下约束:

即最全面的权限管理,它是基于RBAC-0，将RBAC-1和RBAC-2进行了整合。

当平台用户基数增大，角色类型增多时，而且有一部分人具有相同的属性，比如财务部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大。

如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，用户组里的每个用户即可拥有该角色，以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。

根据用户组是否有上下级关系,可以分为有上下级的用户组和普通用户组:

每个公司都会涉及到到组织和职位,下面就重点介绍这两个。

我们可以把组织与角色进行关联，用户加入组织后，就会自动获得该组织的全部角色，无须管理员手动授予，大大减少工作量，同时用户在调岗时，只需调整组织，角色即可批量调整。

组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。

每个组织部门下都会有多个职位，比如财务部有总监，会计，出纳等职位，虽然都在同一部门，但是每个职位的权限是不同的，职位高的拥有更多的权限。

总监拥有所有权限，会计和出纳拥有部分权限。特殊情况下,一个人可能身兼多职。

根据以上场景,新的权限模型就可以设计出来了,如下图:

根据系统的复杂度不同,其中的多对多关系和一对一关系可能会有变化

授权即给用户授予角色,按流程可分为手动授权和审批授权。权限中心可同时配置这两种,可提高授权的灵活性。

有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路:

在项目中可以采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍。

权限系统可以说是整个系统中最基础，同时也可以很复杂的，在实际项目中，会遇到多个系统，多个用户类型，多个使用场景，这就需要具体问题具体分析，但最核心的RBAC模型是不变的,我们可以在其基础上进行扩展来满足需求。

配合在页面上以树形式显示，可以加FATHER_ID,对应的action，这个主要看你具体要实现到什么样的功能

2、再建立一个user_roles用户角色表，user_roles.userid 与 users.id关联。

3、建立一个”用户权限表“sys_permissions，大概字段id、permission，description

4、建一个"用户角色权限表"sys_role_permissions，两个字段roleid、permissionid

5、user_roles.id=sys_role_permissions.roleid 和

sys_permissions.id = sys_role_permissions.permissionid

ADMIN

0表示超级管理员

1表示会员

2表示游客等

然后增加一个权限表

0是管理员的权限内容

1是会员的权限内容

不就OK了

一、申请自己的网站空间和域名

二、制作自己的网站[可以用Dreamwever2008、PS配合,也可以在硅谷动力看视频教程]

三、把自己做好的站上传上去

四、网站的后期维护与管理

五、可以联系我Q275423182

一，掌握权限，理解下面4条基本上就差不多

1，mongodb是没有默认管理员账号，所以要先添加管理员账号，在开启权限认证。

2，切换到admin数据库，添加的账号才是管理员账号。

3，用户只能在用户所在数据库登录，包括管理员账号。

4，管理员可以管理所有数据库，但是不能直接管理其他数据库，要先在admin数据库认证后才可以。这一点比较怪

二，添加管理员账号

[root@localhost zhangy]# mongo

MongoDB shell version: 2.4.6

connecting to: tank

>use admin //切换到admin数据库

switched to db admin

>show collections

system.indexes

system.users //用户表

>db.system.users.find() //用户表没有数据

>db.addUser('tank','test') //添加一个管理员账号

{

"user" : "tank",

"readOnly" : false,

"pwd" : "988432606980d0695e4f668f6bbc643a",

"_id" : ObjectId("529e5d543b6a4608ac833429")

}

三，开启动用户权限认证

[root@localhost zhangy]# vim /etc/mongodb.conf //将auth=true前面的注释拿掉

[root@localhost zhangy]# /etc/init.d/mongod restart //重启生效

四，用户只能在用户所在数据库登录，管理员需要通过admin认证后才能管理其他数据库

[root@localhost zhangy]# mongo

MongoDB shell version: 2.4.6

connecting to: tank

>show dbs //显示所有数据库失败，因为还没有认证

Wed Dec 4 06:39:50.925 listDatabases failed:{ "ok" : 0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:46

>db.auth('tank','test') //认证失败，因为这个用户不属于tank这个数据库

Error: 18 { code: 18, ok: 0.0, errmsg: "auth fails" }

0

>use admin//切换到admin数据库

switched to db admin

>db.auth('tank','test') //在admin数据库认证成功

>use tank //切换到tank数据库

switched to db tank

>show collections //不会在提示没有权限了

contact

system.indexes

users

五，添加普通用启

>use tank

switched to db tank

>db.addUser('tank1','test') //为tank数据库添加了一个可读写用户tank1

{

"_id" : ObjectId("529e5f8474b4c660718a70f3"),

"user" : "tank1",

"readOnly" : false,

"pwd" : "35dd47abff098f5b4f0b567db8edeac5"

}

>db.addUser('tank2','test',true)//为tank数据库添加了一个只读用户tank2

{

"user" : "tank2",

"readOnly" : true,

"pwd" : "1792916c544d247538ded52e6df7b887",

"_id" : ObjectId("529e67553992b24438d5e315")

}

>exit //退出

bye

[root@localhost zhangy]# mongo

MongoDB shell version: 2.4.6

connecting to: tank

>db.auth('tank1','test') //刚添加的用户可以登录。

六，php客户端连接

1， 推荐方法一

$mongo = new Mongo()

$db = $mongo->selectDB('tank') //切换到tank数据库

$db->authenticate("tank3", "test") //认证

$users= $db->selectCollection("users")//选取users表

$cursor = $users->find() //读取数据

foreach ($cursor as $id =>$value) {

echo "$id: "print_r($value)echo "<br>"

}

这种方式比较好理解，根命令行下的操作过程差不多。

2，推荐方法二

$mongo = new Mongo("mongodb://tank3:test@127.0.0.1:27017/tank") //认证用户，这里的数据库，只启认证作用

$db = $mongo->selectDB('tank')//选取数据库

$users= $db->selectCollection("users")

$cursor = $users->find()

foreach ($cursor as $id =>$value) {

echo "$id: "print_r($value)echo "<br>"

}

上面二种方法的不同在于，一个先选数据库在认证，一个先认证在选数据库。

权限管理，最细致的权限管理有 用户，用户组，角色，权限，功能。根据不同的需求适当选择，如 用户量过大，每个人都授权和麻烦，就引入用户组，对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系，需要引入中间表。

本系统设计如下：

数据量很小，功能也不复杂，所以只有用户，角色，权限（功能）及产生的中间表。

表中的数据都是提前填的，用户登陆，查ermroleuser表，获取角色，查ermrolefunction表，获取功能，再查ermfunction表，返回该用户的功能的中文，在页面上展示。

功能权限详细设计请参考，本项目也是受此启发：

http://blog.csdn.net/painsonline/article/details/7183613/

需求：给一个原来没有权限的数据配置系统加上登录，权限功能，不同角色查同一张表返回结果不同。

思路：所谓数据权限，关注点在于实体属性值、条件、允许值，用户登录后，查询该用户的查询条件，根据条件获取数据即可。详细表结构设计可以参考： https://zhuanlan.zhihu.com/p/31339794

具体介绍一下每个字段含义：

（1）主键 id；

（2）acl_id 映射权限点表主键，代表每行记录是针对哪个权限点的；

（3）status 代表当前这条配置是否有效，方便临时激活与禁用；

（4）param 代表需要校验的参数名，允许一个请求有多个参数参与数据校验；如果参数复杂，比如包含对象，定义的参数可能为a.b.c 这种多级的形式，建议不要太复杂

（5）operation 代表数据拦截的规则，使用数字代表是等于、大于、小于、大于等于、小于等于、包含、介于之间等，可以根据自己需要增加或减少支持的拦截规则

（6）value1 和 value2 用来和param、operation组成一个关系表达式，比如：1<=a<2

next_param_op 字段根据需要使用，如果一个权限点支持多条数据规则时，连接两个规则之间的操作，|| 还是 &&

（7）seq 字段用于某个权限点包含多条数据权限规则时的顺序

假设有这么一条数据，那么他的含义是：id为1（acl_id）的权限点，配置了一条有效（status=1）的数据规则，规则是：传入参数id（param）的值要大于（operation）10（value1）

这种设计很细致了，当然我的项目没有那么复杂，所以最终没有采用这个。

http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 讲述了数据权限设计的演化过程。

本系统跟权限相关的表结构如下：