最近手头公司的网站项目终于渐渐走出混沌，走上正轨，任务也轻松了一些，终于有时间整理和总结一下之前做的东西。
以往的项目一般使用模板引擎（如ejs）渲染出完整页面，再发送到浏览器展现。但这次项目的处理方式不同，整个项目由前端AngularJS和后端NodeJS进行了前后端的分离。后端Nodejs提供静态文件服务和API接口，前端则通过AJAX请求调用后端的API，已JSON数据包来进行数据交换。
同时，用户权限管理方面，我选用了RBAC（基于角色的访问控制，Role-based access control）最基本的实现来管理（用户表、角色表、权限表、用户-角色关联表、角色-权限关联表）。而当我实际开发这个模块的时候，立刻就意识到和以往项目的区别：
在使用后端模板引擎渲染页面的时候，后端可以根据用户权限有选择地渲染一些受限的页面元素。
而在前后端分离的开发方式下，由于后端并不渲染任何页面，是否显示某个页面元素，完全是由前端来决定的。
对此，我考虑了一种相对简单的方式：
将用户最终所具有的所有权限通过API返回给前端，前端根据权限控制页面元素。
后端本身就知道用户权限，每个API接口的入口处添加权限的检查。
然而，这样的处理方式是有一定局限性的：
后端每个API入口处都必须写一遍检查。
仅仅到权限级别，太过宽泛，无法进行粒度更小的控制。
权限虽然可以通过用户、角色来实现可配置，但是权限与页面元素、API是否允许调用之间却是由代码编写确定，这部分是无法配置的。
这显然不是我能做到的最佳解决方案。
至少对于后端，我想要的是一种更加灵活可配置，并对业务代码透明的权限检查方式。
于是，我在之前解决方案的基础上，做了进一步细化，并将页面元素、API都当作资源来看待。同时，为了前端可以做更加灵活的控制，页面元素进一步抽象成一份Key-Value数据（我称之为页面环境变量ENV），供前端使用。这样，用户经过RBAC模块最终得到的不是权限，而是“允许访问的API列表（支持*和**通配）”和“环境变量”。
于是，我在权限表之后，又增加了：API路径表、ENV环境变量表、及相关关联表。例如：
角色-权限：
| 角色 | 权限 |
| 用户 | 基础权限 |
| 管理员 | 管理员基础权限 |
| 用户管理员 | 用户管理员权限 |
| 用户管理员首页 |
权限-API路径：
| 权限 | API路径 | 说明 |
| 基础权限 | /public/** | 所有公共资源 |
| /myAccount/** | 个人账户所有操作 | |
| 用户管理员权限 | /manage/users/do/list | 后台管理用户列表 |
| /manage/users/*/do/get | 后台管理查看任意用户信息 |
权限-ENV环境变量：
| 权限 | Key | Value | 说明 |
| 管理员基础权限 | ShowManageBtn | 1 | 显示“管理”按钮 |
| pageSizeForManage | 50 | 后台管理列表页行数 | |
| 用户管理员权限 | ShowManageUsersBtn | 1 | 后台管理显示“用户”按钮 |
| 用户管理员首页 | manageHomePageUrl | /main.html#/manage/users | 后台管理页面首页地址 |
其中，用户最终的API路径表用于后端API进行权限的检查。ENV环境变量返回给前端供其控制页面。
具体而言：
后端只要在请求入口（而不是单个API入口）处，对请求的URL路径和上面的“允许访问的API路径列表”进行比对。请求的路径如在列表中，则通过检查，之后的业务逻辑无需再关心权限问题。如不在列表中，则直接返回拒绝请求。
前端则可以直接使用ENV环境变量中的Key-Value来控制页面，
如配合AngularJS的ng-show： <div ng-show="hasEnv('ShowManageBtn')">...</div>
通过使用这种方式，不仅避免了对每个权限进行 if...else 处理，同时，对后续修改及配置提供了相当大的便利。
当然，这种处理方式也有一些注意点（或者说缺点）。
1. API路径设置要合理有规律，方便通配（单个星号通配1层路径、两个星号通配多层路径）
统一路径命名：如管理类接口都由/manage开头，那么在配置时，只需要使用/manage/**即可通配所有的路径（包括：/manage/home、/manage/users/list）。
做好分层规划：如管理类接口可以按功能细分 /manage/users/**、/manage/posts/**
以统一的动词结尾：如只读权限可以配置为/manage/**/do/get，添加权限可以配置为/manage/**/do/add。
处理对象的ID写进路径：如查看用户信息的路径为 /manage/users/1/do/get、/manage/users/2/do/get，可以配置权限为/manage/users/*/do/get
2. 避免粒度过细
过细的粒度会导致API路径以及ENV环境变量数量的暴增。不仅管理起来麻烦，而且也会一定程度上影响权限检查时的效率。
对于API路径的粒度，一定要严格管理API路径格式以及尽量使用通配，详细见上述第1条。
对于ENV环境变量，可以考虑合并一些总是一起出现的内容。如系统只区分读权限和写权限，则添加、编辑、删除按钮的控制就可以合并为一个 {"btnForWrite": 1} 来处理，而不是为每个按钮都添加一个ENV环境变量。甚至可以将Value设置为一个JSON来保存多个值 {"canWrite":{"addBtn":1, "editBtn":1}}
3. 设置不进行RBAC认证的API路径白名单
比如之前例子中的“基础权限”中的 /public/** 这类肯定允许访问的路径，其实是没有必要特地添加一个权限来管理的。
这类API路径应当写到网站配置中，作为不进行RBAC认证的API路径。
4. 对API路径及ENV环境变量列表进行缓存
每个请求都查询数据库来获取API路径列表显然有点浪费资源。可以针对每个用户，将API列表及环境变量保存到Session中，这样只有第一次请求时才会查询数据库，之后的请求在RBAC检查权限时，只需要从Session取回之前缓存的API列表和ENV环境变量即可。但要注意用户权限在改变时，需要及时令Session中的数据失效。
我在项目中的做法是保存进Redis中，并以 cache@rbac#userId:{userId} 为Key进行保存。当用户角色发生变化时，按照 cache@rbac#userId:{userId} 清除当前用户的权限缓存即可；当角色、权限、API路径、ENV环境变量发生变化时，由于不是很好明确到底影响多少用户，所以直接按照 cache@rbac#userId:* 来清除所有用户的权限缓存。
总结：前后端分离的项目中，
1. 后端服务器仅仅暴露API，所以功能级权限管理可以处理为API的访问控制。
2. 前端页面需要从后端服务器获知如何控制页面元素。同时，直接返回控制方式或具体数值可以减少前端 if...else 数量。