RBAC打造通用WEB权限

 

RBAC不用给用户单个分配权限,只用指向对应的角色就会有对应的权限,而且分配权限和收回权限都很方便

5个关系对应5张表

五张表设计

复制代码
 1 CREATE TABLE `user` (
 2   `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
 3   `name` varchar(20) NOT NULL DEFAULT '' COMMENT '姓名',
 4   `email` varchar(30) NOT NULL DEFAULT '' COMMENT '邮箱',
 5   `is_admin` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否是超级管理员 1表示是 0 表示不是',
 6   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1:有效 0:无效',
 7   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
 8   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
 9   PRIMARY KEY (`id`),
10   KEY `idx_email` (`email`)
11 ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='用户表';
12 
13 CREATE TABLE `role` (
14   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
15   `name` varchar(50) NOT NULL DEFAULT '' COMMENT '角色名称',
16   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1:有效 0:无效',
17   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
18   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
19   PRIMARY KEY (`id`)
20 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色表';
21 
22 CREATE TABLE `user_role` (
23   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
24   `uid` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',
25   `role_id` int(11) NOT NULL DEFAULT '0' COMMENT '角色ID',
26   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
27   PRIMARY KEY (`id`),
28   KEY `idx_uid` (`uid`)
29 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户角色表';
30 
31 CREATE TABLE `access` (
32   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
33   `title` varchar(50) NOT NULL DEFAULT '' COMMENT '权限名称',
34   `urls` varchar(1000) NOT NULL DEFAULT '' COMMENT 'json 数组',
35   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1:有效 0:无效',
36   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
37   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
38   PRIMARY KEY (`id`)
39 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='权限详情表';
40 
41 CREATE TABLE `role_access` (
42   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
43   `role_id` int(11) NOT NULL DEFAULT '0' COMMENT '角色id',
44   `access_id` int(11) NOT NULL DEFAULT '0' COMMENT '权限id',
45   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
46   PRIMARY KEY (`id`),
47   KEY `idx_role_id` (`role_id`)
48 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色权限表';
49 
50 CREATE TABLE `app_access_log` (
51   `id` int(11) NOT NULL AUTO_INCREMENT,
52   `uid` bigint(20) NOT NULL DEFAULT '0' COMMENT '品牌UID',
53   `target_url` varchar(255) NOT NULL DEFAULT '' COMMENT '访问的url',
54   `query_params` longtext NOT NULL COMMENT 'get和post参数',
55   `ua` varchar(255) NOT NULL DEFAULT '' COMMENT '访问ua',
56   `ip` varchar(32) NOT NULL DEFAULT '' COMMENT '访问ip',
57   `note` varchar(1000) NOT NULL DEFAULT '' COMMENT 'json格式备注字段',
58   `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
59   PRIMARY KEY (`id`),
60   KEY `idx_uid` (`uid`)
61 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户操作记录表';
62 
63 
64 INSERT INTO `user` (`id`, `name`, `email`, `is_admin`, `status`, `updated_time`, `created_time`)
65 VALUES(1, '超级管理员', 'apanly@163.com', 1, 1, '2016-11-15 13:36:30', '2016-11-15 13:36:30');
复制代码

用户与角色关联起来,角色与权限关联起来,通过判断角色来管理权限(哪些页面不能访问)

 

判断权限逻辑:根据用户ID取出用户角色==》如果是超级管理员则不需要做权限判断,否则根据角色取出所属权限==》根据权限取出可访问链接列表==》判断当前操作是否在列表中==》无权限则返回提示页面;

 

本内容整理自慕课网视频教程——《RBAC打造通用web管理权限》

RBAC权限管理模型:基本模型及角色模型解析及举例

我们在做任何一款产品的时候,或多或少都会涉及到用户和权限的问题。譬如,做企业类软件,不同部门、不同职位的人的权限是不同的;做论坛类产品的时候,版主和访客权限也是不一样的;再例如一款产品的收费用户和免费用户权限也是迥然不同的。

但在设计产品的用户和权限的关系的时候,很多产品经理可能按照感觉来,在并不清楚用户和权限是否存在优秀的理论模型的时候,就按照自我推理搭建了产品的用户和权限模型。而这种基于感觉和推理的模型肯定是有诸多问题的,譬如写死了关系导致权限不够灵活、考虑不周导致权限覆盖能力弱等等。

正如牛顿所言,站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型,如:RBAC(Role-Based Access Control)——基于角色的访问控制。我搜集了网上很多关于RBAC的资料,大多与如何用数据表实现RBCA相关,并不容易理解。所以,我会以产品经理的角度去解析RBAC模型,并分别举例如何运用这套已得到验证的成熟模型。

一、RBAC模型是什么?

RBAC是一套成熟的权限模型。在传统权限模型中,我们直接把权限赋予用户。而在RBAC中,增加了“角色”的概念,我们首先把权限赋予角色,再把角色赋予用户。这样,由于增加了角色,授权会更加灵活方便。在RBAC中,根据权限的复杂程度,又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0是基础,RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度,选取适合的权限模型。

1

二、基本模型RBAC0

解析:

RBAC0是基础,很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中,我们把权限赋予角色,再把角色赋予用户。用户和角色,角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。

2

举例:

譬如我们做一款企业管理产品,如果按传统权限模型,给每一个用户赋予权限则会非常麻烦,并且做不到批量修改用户权限。这时候,可以抽象出几个角色,譬如销售经理、财务经理、市场经理等,然后把权限分配给这些角色,再把角色赋予用户。这样无论是分配权限还是以后的修改权限,只需要修改用户和角色的关系,或角色和权限的关系即可,更加灵活方便。此外,如果一个用户有多个角色,譬如王先生既负责销售部也负责市场部,那么可以给王先生赋予两个角色,即销售经理+市场经理,这样他就拥有这两个角色的所有权限。

三、角色分层模型RBAC1

解析:

RBAC1建立在RBAC0基础之上,在角色中引入了继承的概念。简单理解就是,给角色可以分成几个等级,每个等级权限不同,从而实现更细粒度的权限管理。

3

举例:

基于之前RBAC0的例子,我们又发现一个公司的销售经理可能是分几个等级的,譬如除了销售经理,还有销售副经理,而销售副经理只有销售经理的部分权限。这时候,我们就可以采用RBAC1的分级模型,把销售经理这个角色分成多个等级,给销售副经理赋予较低的等级即可。

四、角色限制模型RBAC2

解析:

RBAC2同样建立在RBAC0基础之上,仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图:

4

举例:

还是基于之前RBAC0的例子,我们又发现有些角色之间是需要互斥的,譬如给一个用户分配了销售经理的角色,就不能给他再赋予财务经理的角色了,否则他即可以录入合同又能自己审核合同;再譬如,有些公司对角色的升级十分看重,一个销售员要想升级到销售经理,必须先升级到销售主管,这时候就要采用先决条件限制了。

五、统一模型RBAC3

解析:

RBAC3是RBAC1和RBAC2的合集,所以RBAC3既有角色分层,也包括可以增加各种限制。

5

举例:

这个就不举例了,统一模型RBAC3可以解决上面三个例子的所有问题。当然,只有在系统对权限要求非常复杂时,才考虑使用此权限模型。

六、基于RBAC的延展——用户组

解析:

基于RBAC模型,还可以适当延展,使其更适合我们的产品。譬如增加用户组概念,直接给用户组分配角色,再把用户加入用户组。这样用户除了拥有自身的权限外,还拥有了所属用户组的所有权限。

6

举例:

譬如,我们可以把一个部门看成一个用户组,如销售部,财务部,再给这个部门直接赋予角色,使部门拥有部门权限,这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权,且不影响用户本来就拥有的角色权限。

七、最后的话

无论是本次的权限模型,还是其他产品相关实现方案,很多都已经被前人所总结提炼,我们应深度掌握这些成熟的知识和经验,而不是绞尽脑汁自我推理。还是文章开头那句话,站在巨人的肩膀上我们可以看得更远,而不是再造一个轮子。

RBAC权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)

角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。

 

当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)


请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

 

这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。

 

这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

 

到这里,RBAC权限模型的扩展模型的完整设计图如下:


随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要参于权限分配。

Nginx内置变量以及日志格式变量参数详解

Nginx内置变量以及日志格式变量参数详解

$args                    #请求中的参数值
$query_string            #同 $args
$arg_NAME                #GET请求中NAME的值
$is_args                 #如果请求中有参数,值为"?",否则为空字符串
$uri                     #请求中的当前URI(不带请求参数,参数位于$args),可以不同于浏览器传递的$request_uri的值,它可以通过内部重定向,或者使用index指令进行修改,$uri不包含主机名,如"/foo/bar.html"。
$document_uri            #同 $uri
$document_root           #当前请求的文档根目录或别名
$host                    #优先级:HTTP请求行的主机名>"HOST"请求头字段>符合请求的服务器名.请求中的主机头字段,如果请求中的主机头不可用,则为服务器处理请求的服务器名称
$hostname                #主机名
$https                   #如果开启了SSL安全模式,值为"on",否则为空字符串。
$binary_remote_addr      #客户端地址的二进制形式,固定长度为4个字节
$body_bytes_sent         #传输给客户端的字节数,响应头不计算在内;这个变量和Apache的mod_log_config模块中的"%B"参数保持兼容
$bytes_sent              #传输给客户端的字节数
$connection              #TCP连接的序列号
$connection_requests     #TCP连接当前的请求数量
$content_length          #"Content-Length" 请求头字段
$content_type            #"Content-Type" 请求头字段
$cookie_name             #cookie名称
$limit_rate              #用于设置响应的速度限制
$msec                    #当前的Unix时间戳
$nginx_version           #nginx版本
$pid                     #工作进程的PID
$pipe                    #如果请求来自管道通信,值为"p",否则为"."
$proxy_protocol_addr     #获取代理访问服务器的客户端地址,如果是直接访问,该值为空字符串
$realpath_root           #当前请求的文档根目录或别名的真实路径,会将所有符号连接转换为真实路径
$remote_addr             #客户端地址
$remote_port             #客户端端口
$remote_user             #用于HTTP基础认证服务的用户名
$request                 #代表客户端的请求地址
$request_body            #客户端的请求主体:此变量可在location中使用,将请求主体通过proxy_pass,fastcgi_pass,uwsgi_pass和scgi_pass传递给下一级的代理服务器
$request_body_file       #将客户端请求主体保存在临时文件中。文件处理结束后,此文件需删除。如果需要之一开启此功能,需要设置client_body_in_file_only。如果将次文件传 递给后端的代理服务器,需要禁用request body,即设置proxy_pass_request_body off,fastcgi_pass_request_body off,uwsgi_pass_request_body off,or scgi_pass_request_body off
$request_completion      #如果请求成功,值为"OK",如果请求未完成或者请求不是一个范围请求的最后一部分,则为空
$request_filename        #当前连接请求的文件路径,由root或alias指令与URI请求生成
$request_length          #请求的长度 (包括请求的地址,http请求头和请求主体)
$request_method          #HTTP请求方法,通常为"GET"或"POST"
$request_time            #处理客户端请求使用的时间,单位为秒,精度毫秒; 从读入客户端的第一个字节开始,直到把最后一个字符发送给客户端后进行日志写入为止。
$request_uri             #这个变量等于包含一些客户端请求参数的原始URI,它无法修改,请查看$uri更改或重写URI,不包含主机名,例如:"/cnphp/test.php?arg=freemouse"
$scheme                  #请求使用的Web协议,"http" 或 "https"
$server_addr             #服务器端地址,需要注意的是:为了避免访问linux系统内核,应将ip地址提前设置在配置文件中
$server_name             #服务器名
$server_port             #服务器端口
$server_protocol         #服务器的HTTP版本,通常为 "HTTP/1.0" 或 "HTTP/1.1"
$status                  #HTTP响应代码
$time_iso8601            #服务器时间的ISO 8610格式
$time_local              #服务器时间(LOG Format 格式)
$cookie_NAME             #客户端请求Header头中的cookie变量,前缀"$cookie_"加上cookie名称的变量,该变量的值即为cookie名称的值
$http_NAME               #匹配任意请求头字段;变量名中的后半部分NAME可以替换成任意请求头字段,如在配置文件中需要获取http请求头:"Accept-Language",$http_accept_language即可
$http_cookie
$http_host               #请求地址,即浏览器中你输入的地址(IP或域名)
$http_referer            #url跳转来源,用来记录从那个页面链接访问过来的
$http_user_agent         #用户终端浏览器等信息
$http_x_forwarded_for
$sent_http_NAME          #可以设置任意http响应头字段;变量名中的后半部分NAME可以替换成任意响应头字段,如需要设置响应头Content-length,$sent_http_content_length即可
$sent_http_cache_control
$sent_http_connection
$sent_http_content_type
$sent_http_keep_alive
$sent_http_last_modified
$sent_http_location
$sent_http_transfer_encoding

log_format有一个默认的、无须设置的combined日志格式设置,相当于Apache的combined日志格式,其具体参数如下:

log_format combined  ‘$remote_addr-$remote_user [$time_local]’

‘ “$request” $status $body_bytes_sent’

‘ “$http_referer” “$http_user_agent” ‘;

 

我现在使用的日志格式:

log_format access  ‘$http_x_forwarded_for $remote_addr [$time_local] “http://$host” “$request” ‘
‘$status $body_bytes_sent “$http_referer” “$http_user_agent” “$remote_user” ‘;

当日志文件中记录的值为”“时,表示为空

access为自定义的日志格式的名称,使用时引用即可:

access_log  /data/logs/nginx/ihouse_access.log access;

——————————————————————————————————

正确设置nginx中remote_addr和x_forwarded_for参数

什么是remote_addr:

remote_addr代表客户端的IP,但它的值不是由客户端提供的,而是服务端根据客户端的ip指定的,当你的浏览器访问某个网站时,假设中间没有任何代理,那么网站的web服务器(Nginx,Apache等)就会把remote_addr设为你的机器IP,如果你用了某个代理,那么你的浏览器会先访问这个代理,然后再由这个代理转发到网站,这样web服务器就会把remote_addr设为这台代理机器的IP

什么是x_forwarded_for:

正如上面所述,当你使用了代理时,web服务器就不知道你的真实IP了,为了避免这个情况,代理服务器通常会增加一个叫做x_forwarded_for的头信息,把连接它的客户端IP(即你的上网机器IP)加到这个头信息里,这样就能保证网站的web服务器能获取到真实IP

使用HAProxy做反向代理时

通常网站为了支撑更大的访问量,会增加很多web服务器,并在这些服务器前面增加一个反向代理(如HAProxy),它可以把负载均匀的分布到这些机器上。你的浏览器访问的首先是这台反向代理,它再把你的请求转发到后面的web服务器,这就使得web服务器会把remote_addr设为这台反向代理的IP,为了能让你的程序获取到真实的客户端IP,你需要给HAProxy增加以下配置

   option forwardfor

它的作用就像上面说的,增加一个x_forwarded_for的头信息,把客户端的ip添加进去,否则的话经测试为空值

如上面的日志格式所示:$http_x_forwarded_for 是客户端真实的IP地址,$remote_addr是前端Haproxy的IP地址

或者:

当Nginx处在HAProxy后面时,就会把remote_addr设为HAProxy的IP,这个值其实是毫无意义的,你可以通过nginx的realip模块,让它使用x_forwarded_for里的值。使用这个模块需要重新编译Nginx,增加--with-http_realip_module参数

./configure  –user=www –group=www –prefix=/usr/local/nginx –with-http_stub_status_module –with-http_ssl_module \                                                              –with-http_realip_module –http-log-path=/data/logs/nginx/access.log –error-log-path=/data/logs/nginx/error.log

     set_real_ip_from 10.1.10.0/24;

     real_ip_header X-Forwarded-For;

上面的两行配置就是把从10.1.10这一网段过来的请求全部使用X-Forwarded-For里的头信息作为remote_addr,这样此时remote_addr就是客户端真实的IP地址

————————————————————–

X-Forwarded-For 和 X-Real-IP 获取客户端的ip的区别:

一般来说,X-Forwarded-For是用于记录代理信息的,每经过一级代理(匿名代理除外),代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中 来自4.4.4.4的一个请求,header包含这样一行 X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3 代表 请求由1.1.1.1发出,经过三层代理,第一层是2.2.2.2,第二层是3.3.3.3,而本次请求的来源IP 4.4.4.4是第三层代理 而X-Real-IP,一般记录真实发出请求的客户端IP,上面的例子,如果配置了X-Read-IP,将会是 X-Real-IP: 1.1.1.1 所以 ,如果只有一层代理,这两个头的值就是一样的

 

 

 

所有相关变量具体请详看官网:

http://nginx.org/en/docs/varindex.html

http://blog.csdn.net/njxdy/article/details/9998481