前言
所谓权限，无非就是哪些用户允许干哪些事情，能够访问、操作哪些资源（web通常以url为粒度）。一般的后台管理（配置）系统都会做相应的权限控制（往往以用户-角色-资源为基础）。
用户-角色-资源（user-role-resource）
在实际业务中，某一类可以访问/操作的资源或者页面往往是对应某一类用户的。
例如：一个教务管理系统，小明同学、小红同学等用户可以进去查成绩，看课程安排；而张老师、王老师等用户则可以进去录入、修改学生成绩；资源表内容如下：
| id | description | url |
|---|---|---|
| 1 | 获取成绩 | /mark/get |
| 2 | 获取课程 | /course/get |
| 3 | 录入成绩 | /mark/add |
| 4 | 修改成绩 | /mark/modify |
学生这一类用户允许访问id为1和2的资源；
老师这一类用户允许访问id为3和4的资源；
我们将拥有共同访问资源的某一类用户，统称为某个角色（role）或某个用户组（group），用户属于某个角色，而这个角色会有属于它可以访问的资源。
如上面的小明同学属于学生这个角色，而学生这个角色有id为1、2的资源，即可以查成绩、获取课程等，但是没有老师这个角色的资源（录入和修改成绩等）。
当有一个新的同学（user）录入时，系统则可以直接将该user设定为学生这个角色，即可拥有其对应的所有权限。
数据库表设计
用户和角色为多对多关系：一个角色是对应有多个用户的（学生-->小明、小红）；另外，一个用户可能会有多个角色，例如小杰是一个在读研究生（学生），但是也会给大一的同学讲课（老师）；
角色和资源为多对多关系：一个角色是对应多个资源的（学生-->查看成绩、获取课程）；另外，一个资源也是可以被多个角色访问的，例如修改个人信息，无论学生还是老师都可以拥有的。
具体表结构设计如下：
实际拦截操作
当用户登录之后，系统可以查询数据库，user-->role-->resource获取其可以访问/操作的资源。当该用户访问某个url时，例如/mark/modify ，web后台会设置一个专门的权限拦截器，比对判断该用户是否拥有该权限而做出相应处理。
其他拓展
- 不同的业务可能会有不同的设计，例如目前很多管理系统往往一个用户只会对应一个角色，这样也满足了实际需求；而这时候角色和用户就是1对多的情况了。
- 另外也存在这样的业务需求：用户除了其对应角色的权限外，还希望为该用户有其额外/特殊的对应的可访问资源，这时候user和resource之间会建立起来一个类似role_resource的多对多关系。
- 对于角色（role），有时候会有父级的设计（多一个parent_id字段等），这时候表示子级的角色可以访问父级的资源，属于一个权限拓展的过程。比如美国大片中小士兵的id为1，而比他高一级的排长的parent_id则为1，这时候排长起码会有小士兵的权限；再上一级，连长的parent_id则是排长的id，一级一级下去。
- 还有一些的资源会细分到以某个函数为粒度的，这时候表设计仍然类似，具体拦截方法不一样而已。
虽然拓展性有很多，但是不建议将权限关系弄得过于复杂，满足自身业务需求即可。
