最近做一个基于nodejs的权限管理，查阅了一两天，发现大致是这样的：
passportjs
node-oauth
rbac
node_acl
express_acl
connect-roles
需求
按照模块，页面，API等级别做权限控制，暂时不需要做到按钮级别
主要程序开发完毕，需要侵入少
存储主要考虑redis
自己开发管理页面，方便自定义和维护
选取原则
轻量级别
passportjs太强大，大到怕怕
文档清晰（示例|API）
node_acl的readme 我只能说，真的是很友好，API也不多但是都非常get到点
好上手
容易扩展
功能强大或者适用
代码侵入少
最讨厌到处修改代码
人气指数相对比较高
最后选择了node_acl,主要是
人气相对比较高，大约2000star，
其次功能本身很独立，提供内存，mongo和redis三种存储方式
API简单好用
文档好读
源码不多，方便去自定义和扩展
我们主要程序开发完毕，需要侵入少，研究后发现node_acl应该可以
确认node_acl后，就开始研究一些小细节和设计，说这么多，就是自己写一点代码进行接口功能测试。
问题列表：
权限继承
addRoleParents满足需求，确实好用。比如guest, user ,admin三个Role, user集成guest, admin集成user。然后对不同的Role进行权限配置。还是不错的
Resource 不支持同配
这是什么意思，比如消息有下面几个路径, /msg/delete, msg/add, /msg/list,你就必须一条一条的配置，是不是很狗血
Added the possibility to have a wildcard in resource name
不提供所有的Role查询的API
我进入后，居然不知道有多少种Role
删除角色后，数据有残存
需要引入模块来关联页面或者API
初始化需要有超级管理员
默认设置，全部允许？全部不允许访问？
是否引入目录继承关系
。。。。。。
这里扒拉扒拉写这么多，很多只要API能做到，剩下的就是设计问题。麻烦的问题来了
Resource不支持通配
不提供所有的Role查询的API
这两个底层基本的功能不支持，还玩个蛋。
冷静，冷静，我们打开源码，会发现，插件一共就7个js(版本0.4.11)
acl.js
核心之核心文件，暴露Role,Resource, Permission等等的API
backend.js
backend API定义，并没实际作用
contract.js
参数验证js
memory-backend.js
内存中存储
mongodb-backend.js
mongodb存储
redis-backend.js
redis存储
index.js
默认文件
三种backend都是存储数据的，那我们先导出数据来看一看：
关于怎么导出redis
安装redis-dump
edis-dump -h 127.0.0.1 -d 0 --json > c:\db.json
我们看一看导出的文件
{ "acl_allows_/@guest": { "type": "set", "value": [ "*" ] }, "acl_allows_/about@guest": { "type": "set", "value": [ "*" ] }, "acl_allows_/index@guest": { "type": "set", "value": [ "*" ] }, "acl_meta@roles": { "type": "set", "value": [ "guest" ] }, "acl_meta@users": { "type": "set", "value": [ "1024" ] }, "acl_resources@guest": { "type": "set", "value": [ "http://www.likecs.com/", "/about", "/index" ] }, "acl_roles@user": { "type": "set", "value": [ "1024" ] }, "acl_users@1024": { "type": "set", "value": [ "user" ] } }