原文链接:简书
有人说,每个人都是平等的;
也有人说,人生来就是不平等的;
在人类社会中,并没有绝对的公平,
一件事,并不是所有人都能去做;
一样物,并不是所有人都能够拥有。
每个人都有自己的角色,每种角色都有对某种资源的一定权利,或许是拥有,或许只能是远观而不可亵玩。
把这种人类社会中如此抽象的事实,提取出来,然后写成程序,还原本质的工作,就是我们程序员该做的事了。
有了一个这么有范儿的开头,下面便来谈谈基于RESTful,如何实现不同的人不同的角色对于不同的资源不同的操作的权限控制。
本文是基于RESTful描述的,需要你对这个有初步的了解。
RESTful是什么?
Representational State Transfer,简称REST,是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。
REST比较重要的点是资源和状态转换,
所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。
而"状态转换",则是把对应的HTTP协议里面,四个表示操作方式的动词分别对应四种基本操作:
1. GET,用来浏览(browse)资源
2. POST,用来新建(create)资源
3. PUT,用来更新(update)资源
4. DELETE,用来删除(delete)资源。
清楚了资源的概念,然后再来对资源进行一下分类,我把资源分为下面三类:
1. 私人资源 (Personal Source)
2. 角色资源 (Roles Source)
3. 公共资源 (Public Source)
"私人资源":是属于某一个用户所有的资源,只有用户本人才能操作,其他用户不能操作。例如用户的个人信息、订单、收货地址等等。
"角色资源":与私人资源不同,角色资源范畴更大,一个角色可以对应多个人,也就是一群人。如果给某角色分配了权限,那么只有身为该角色的用户才能拥有这些权限。例如系统资源只能够管理员操作,一般用户不能操作。
"公共资源":所有人无论角色都能够访问并操作的资源。
而对资源的操作,无非就是分为四种:
1. 浏览 (browse)
2. 新增 (create)
3. 更新 (update)
4. 删除 (delete)
角色和用户的概念,自不用多说,大家都懂,但是权限的概念需要提一提。
"权限",就是资源与操作的一套组合,例如"增加用户"是一种权限,"删除用户"是一种权限,所以对于一种资源所对应的权限有且只有四种。
角色与用户的关系:一个角色对应一群用户,一个用户也可以扮演多个角色,所以它们是多对多的关系。
角色与权限的关系:一个角色拥有一堆权限,一个权限却只能属于一个角色,所以它们是一(角色)对多(权限)的关系
权限与用户的关系:由于一个用户可以扮演多个角色,一个角色拥有多个权限,所以用户与权限是间接的多对多关系。
需要注意两种特别情况:
1. 私人资源与用户的关系,一种私人资源对应的四种权限只能属于一个用户,所以这种情况下,用户和权限是一(用户)对多(权限)的关系。
2. 超级管理员的角色,这个角色是神一般的存在,能无视一切阻碍,对所有资源拥有绝对权限,甭管你是私人资源还是角色资源。
角色、用户、权限的模型应该怎么样设计,才能满足它们之间的关系?
对上图的一些关键字段进行说明:
在sails下称为策略(Policy),在java SSH下称为过滤器(Filter),无论名称如何,他们工作原理是大同小异的,主要是在一条HTTP请求访问一个Controller下的action之前进行检测。所以在这一层,我们可以自定义一些策略/过滤器来实现权限控制。
为行文方便,下面姑且允许我使用策略这一词。
*策略 (Policy) *
下面排版顺序对应Policy的运行顺序
如果通过所有policy的检测,则把请求转发到目标action。
在Sails下,有一个很方便的套件sails-permissions,集成了一套权限管理的方案,本文也是基于该套件的源码所引出来的权限管理解决方案。
对程序员最大的挑战,并不是能否掌握了哪些编程语言,哪些软件框架,而是对业务和需求的理解,然后在此基础上,把要点抽象出来,写成计算机能理解的语言。
最后,希望这篇文章,能够帮助你对权限管理这一课题增加多一点点理解。
1
jedrek 2015-03-29 22:04:20 +08:00 2
权限控制是程序的事,跟是否RESTful设计没有半点关系
|
5
zieglar 2015-03-29 22:25:17 +08:00
做为一个 Sails.js 的使用者,从这个代码来看我觉得很蛋疼的
强制定义的东西太多 其实直接用 OAuth2.0 的 scope 就可以解决很多权限的问题 |
6
ywisax 2015-03-30 00:18:08 +08:00
mark
|
7
fengchang 2015-03-30 09:19:25 +08:00
我也觉得auth token是对你标题的回答。内容和RESTful没有关系
|
8
caixiexin 2015-03-30 09:44:18 +08:00
先mark后看。。
我觉得权限控制其实跟RESTful无关吧,传统的管理系统就采用 RBAC,开放式的api就采用OAuth认证,都是程序上实现的逻辑,而RESTful只是对这些程序以及资源在url上一种优雅的描述。 个人看法,大牛轻拍= =|| |
9
hbin 2015-03-30 09:44:42 +08:00
严格来讲,应该用 PATCH 而不是 PUT 去更新(FYI: http://tools.ietf.org/html/rfc5789)
|
10
luchen3256 2015-03-30 09:59:27 +08:00
这个图是用什么工具画的?
|
11
JerryC OP @luchen3256 ProcessOn
|
13
JerryC OP 但是看各位的评论,就能让我收获良多呀~~
|
14
tabris17 2015-03-30 13:48:20 +08:00
使用HTTP协议的基本身份验证。添加Authorization头部
|
15
reorx 2015-03-31 10:04:28 +08:00 via iPhone
@caixiexin +1
另外对一个资源的操作不一定只有 CRUD 四种,所有符合系统逻辑的原子操作都是,可以理解为你为某种资源的操作所封装的函数,permission 是用来控制是否允许用户对这些函数进行调用 |
16
wuyu1998 2015-04-05 14:53:00 +08:00
1个角色,拥有n个权限。
2个角色的权限交集,应该允许非空。 权限 <===> 角色 <===> 用户 感觉3者之间都是多对多的关系。而且,不允许将权限直接赋予用户。 你描述的模型,只限制到表的记录级别,字段级别的权限控制,也应该有。 如果要求控制到字段级别,RESTful的返回,很麻烦。 |
17
laball 2018-02-13 10:59:54 +08:00
角色与权限的关系:一个角色拥有一堆权限,一个权限却只能属于一个角色,所以它们是一(角色)对多(权限)的关系
好像有点不对吧!!!! |