基于RESTful API 怎么设计用户权限控制？

前言

有人说，每一个人都是平等的；
也有人说，人生来就是不平等的；
在人类社会中，并无绝对的公平，
一件事，并非全部人都能去作；
同样物，并非全部人都可以拥有。
每一个人都有本身的角色，每种角色都有对某种资源的必定权利，或许是拥有，或许只能是远观而不可亵玩。
把这种人类社会中如此抽象的事实，提取出来，而后写成程序，还本来质的工做，就是咱们程序员该作的事了。
有了一个这么有范儿的开头，下面便来谈谈基于RESTful，如何实现不一样的人不一样的角色对于不一样的资源不一样的操做的权限控制。

RESTful简述

本文是基于RESTful描述的，须要你对这个有初步的了解。
RESTful是什么？
Representational State Transfer，简称REST，是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。
REST比较重要的点是资源和状态转换，
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它能够是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。
而"状态转换"，则是把对应的HTTP协议里面，四个表示操做方式的动词分别对应四种基本操做：

1. GET，用来浏览(browse)资源
2. POST，用来新建(create)资源
3. PUT，用来更新(update)资源
4. DELETE，用来删除(delete)资源。

RESTful CURD

资源的分类及操做

清楚了资源的概念，而后再来对资源进行一下分类，我把资源分为下面三类：

1. 私人资源 (Personal Source)
2. 角色资源 (Roles Source)
3. 公共资源 (Public Source)

Sources

"私人资源"：是属于某一个用户全部的资源，只有用户本人才能操做，其余用户不能操做。例如用户的我的信息、订单、收货地址等等。
"角色资源"：与私人资源不一样，角色资源范畴更大，一个角色能够对应多我的，也就是一群人。若是给某角色分配了权限，那么只有身为该角色的用户才能拥有这些权限。例如系统资源只可以管理员操做，通常用户不能操做。
"公共资源"：全部人不管角色都可以访问并操做的资源。

而对资源的操做，无非就是分为四种：

1. 浏览 (browse)
2. 新增 (create)
3. 更新 (update)
4. 删除 (delete)

角色、用户、权限之间的关系

角色和用户的概念，自不用多说，你们都懂，可是权限的概念须要提一提。
"权限"，就是资源与操做的一套组合，例如"增长用户"是一种权限，"删除用户"是一种权限，因此对于一种资源所对应的权限有且只有四种。

Permissions

角色与用户的关系：一个角色对应一群用户，一个用户也能够扮演多个角色，因此它们是多对多的关系。
角色与权限的关系：一个角色拥有一堆权限，一个权限却只能属于一个角色，因此它们是一(角色)对多(权限)的关系
权限与用户的关系：因为一个用户能够扮演多个角色，一个角色拥有多个权限，因此用户与权限是间接的多对多关系。

Relations

须要注意两种特别状况：

1. 私人资源与用户的关系，一种私人资源对应的四种权限只能属于一个用户，因此这种状况下，用户和权限是一(用户)对多(权限)的关系。
2. 超级管理员的角色，这个角色是神通常的存在，能无视一切阻碍，对全部资源拥有绝对权限，甭管你是私人资源仍是角色资源。

数据库表的设计

角色、用户、权限的模型应该怎么样设计，才能知足它们之间的关系？

Models

对上图的一些关键字段进行说明：

Source

• name: 资源的名称，也就是其余模型的名称，例如：user、role等等。
• identity: 资源的惟一标识，能够像uuid，shortid这些字符串，也能够是model的名称。
• permissions : 一种资源对应有四种权限，分别对这种资源的browse、create、update、delete

Permission

• source : 该权限对应的资源，也就是Source的某一条记录的惟一标识
• action ：对应资源的操做，只能是browse、create、update、delete四个之一
• relation：用来标记该权限是属于私人的，仍是角色的，用于OwnerPolicy检测
• roles: 拥有该权限的角色

Role

• users : 角色所对应的用户群，一个角色能够对应多个用户
• permissions: 权限列表，一个角色拥有多项权利

User

• createBy : 该记录的拥有者，在user标里，通常等于该记录的惟一标识，这一属性用于OwnerPolicy的检测，其余私有资源的模型设计，也须要加上这一字段来标识资源的拥有者。
• roles : 用户所拥有的角色

策略/过滤器

在sails下称为策略(Policy)，在java SSH下称为过滤器(Filter)，不管名称如何，他们工做原理是大同小异的，主要是在一条HTTP请求访问一个Controller下的action以前进行检测。因此在这一层，咱们能够自定义一些策略/过滤器来实现权限控制。
为行文方便，下面姑且容许我使用策略这一词。

策略 (Policy)

下面排版顺序对应Policy的运行顺序

1. SessionAuthPolicy：
   检测用户是否已经登陆，用户登陆是进行下面检测的前提。
2. SourcePolicy：
   检测访问的资源是否存在，主要检测Source表的记录
3. PermissionPolicy：
   检测该用户所属的角色，是否有对所访问资源进行对应操做的权限。
4. OwnerPolicy：
   若是所访问的资源属于私人资源，则检测当前用户是否该资源的拥有者。

若是经过全部policy的检测，则把请求转发到目标action。

Policies

Sails下的权限控制实现

在Sails下，有一个很方便的套件sails-permissions，集成了一套权限管理的方案，本文也是基于该套件的源码所引出来的权限管理解决方案。

结语

对程序员最大的挑战，并非可否掌握了哪些编程语言，哪些软件框架，而是对业务和需求的理解，而后在此基础上，把要点抽象出来，写成计算机能理解的语言。最后，但愿这篇文章，可以帮助你对权限管理这一课题增长多一点点理解。