数据库权限管理设计-帝国权限数据库表设计

1 简介

据说人人平等；

也有人说数据库权限管理设计，人生来不平等；

人类社会，没有绝对的公平，

一件事，不是每个人都能做到；

一件事，不是每个人都能拥有它。

每个人都有自己的角色，每个角色对某种资源都有一定的权利，也许是拥有的，也许只能远观不能玩。

把人类社会中这样抽象的事实提炼出来，写进程序数据库权限管理设计，还原本质，才是我们程序员应该做的。

有了这么花俏的开篇，我们就来说说如何基于RESTful实现不同人、不同角色对不同资源的不同操作的权限控制。

2 RESTful简介

本文基于RESTful的描述，需要你对此有一个初步的了解。

什么是 RESTful？

Representational State Transfer，简称REST，是Roy Fielding博士在2000年的博士论文中提出的一种软件架构风格。

REST比较重要的点是资源和状态转换。

所谓“资源”就是网络上的一个实体，或者说是网络上的一条特定信息。 它可以是一段文字、一张图片、一首歌、一项服务，总之就是一个具体的现实。

“状态转换”指的是对应四种基本操作的HTTP协议中相应的四个动词：

GET，用于浏览（browse）资源

POST，用于创建新资源

PUT，用于更新（update）资源

DELETE，用于删除（delete）资源。

RESTful凝乳

3 资源分类与运营

明确了资源的概念之后，我们来对资源进行分类。 我把资源分为以下三类：

个人来源

角色来源

公共资源

来源

“私有资源”：是某个用户拥有的资源，只有该用户可以操作，其他用户不能操作。 例如，用户的个人信息、订单、送货地址等。

“角色资源”：与私有资源不同，角色资源的范围更大，一个角色可以对应多个人，也就是一群人。 如果将权限分配给角色，则只有该角色中的用户才能拥有这些权限。 比如系统资源只能由管理员操作，普通用户不能操作。

“公共资源”：每个人都可以访问和操作的资源，无论其角色如何。

对资源的操作无非分为四种：

浏览

添加（创建）

更新

删除

4 角色、用户和权限的关系

角色和用户的概念不用说大家都懂，但是权限的概念就需要提一下。

“权限”是资源和操作的结合。 比如“添加用户”是一种权限，“删除用户”是一种权限。 因此，一个资源对应的权限只有四种。

权限

角色与用户的关系：一个角色对应一组用户，一个用户也可以扮演多个角色，是多对多的关系。

角色和权限的关系：一个角色有一堆权限，但是一个权限只能属于一个角色，所以他们是一对（角色）对多（权限）的关系

权限和用户的关系：由于一个用户可以扮演多个角色，一个角色有多个权限，所以用户和权限是间接的多对多关系。

关系

有两种特殊情况需要注意：

私有资源与用户的关系，一个私有资源对应的四种权限只能属于一个用户，所以在这种情况下，用户与权限的关系是一（用户）对多（权限）。

超级管理员的角色，这个角色是神一般的存在，可以无视一切障碍，对所有资源拥有绝对的权限，不管你是私有资源还是角色资源。

5 数据库表的设计

应该如何设计角色、用户和权限的模型来满足它们之间的关系？

楷模

解释上图中的一些关键字段：

来源

允许

角色

用户

6 政策/过滤器

在sails下称为policy，在java SSH下称为filter。 不管叫什么名字，它们的工作原理都是相似的，主要是在HTTP请求访问Controller下的action之前进行检测。 所以在这一层，我们可以自定义一些策略/过滤器来实现权限控制。

为了写作方便，下面还是用策略这个词吧。

政策

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

会话验证策略：

检测用户是否已经登录，用户登录是下面检测的前提。

来源政策：

检测访问的资源是否存在，主要检测Source表中的记录

许可政策：

检测用户所属的角色，是否有权限对访问的资源进行相应的操作。

所有者政策：

如果访问的资源是私有资源，检查当前用户是否是该资源的拥有者。

如果所有策略检查都通过，请求将转发到目标操作。

政策

7 Sails下权限控制的实现

在Sails下，有一个非常方便的套件sails-permissions，它集成了一套权限管理方案。 本文也是基于套件源码衍生出的权限管理方案。

8结语

程序员最大的挑战不是能不能掌握哪些编程语言和软件框架，而是对业务和需求的理解，然后在此基础上，抽象出关键点，写成计算机能看懂的语言。

最后，希望本文能帮助您对权限管理这一主题有更多的了解。