@
ikas 关于 Resource-Based Access Control 模式，各种博客和技术文章的说法不一样，我曾经困惑了很久，和朋友研究了一个星期，直到看见了 stack overflow 的回答：
https://stackoverflow.com/questions/18435219/resource-based-access-control-vs-role-based-access-controlResource-Based Access Control 这个名词出自于一个国外程序员写的一篇博客中（ stackoverflow 的问题给出了原文地址），这个程序员自己定义的一个新名词，而且只有他自己一个人在用，不是通用模型。我看了那篇博客原文，Resource-Based Access Control 所定义的内容，就是 RBAC(role-based-access-control)的具体实现。而 RBAC(role-based-access-control)是 NIST 定义的标准，是一个理论模型。中文资料中关于 Resource-Based Access Control 的定义要么是翻译了原文，要么是在原文基础上二次修改。英文资料已经找不到关于 Resource-Based Access Control 的定义了，博客原文都打不开了。虽然我们常用的权限系统的设计和那篇博客的所描述的内容大同小异，但我不建议使用 Resource-Based Access Control 这个词，这个词和 RBAC 放一起容易混淆，而且找不到关于这个名词的标准定义。
常用的关于权限系统的设计模型有两个（维基百科英文版给出了很详细的描述）
ACL(Access control list)：用户、权限。用户名下直接挂权限，优点：灵活。缺点：要给每个用户都设置权限，繁琐。
RBAC：用户、角色、权限。用户名下挂角色，角色名下挂权限。优点：简化了给用户设置权限的步骤，满足的大部分业务场景。缺点：灵活性稍微低一点
现在业务系统几乎都是基于 RBAC 设计权限。除非客户强制提需求：“我就不想新增一个角色，就想单独改一个人的权限”，特殊情况下才用 ACL 。
前后端分离的情况下，权限管理被分割成了两部分：
1. UI 界面组件的显示权限（也称为菜单权限、按钮权限、目录权限等）
2. 服务器 API 的访问权限（也称为资源权限 resource ）
当给一个用户授权某个功能的使用权时，至少需要授予两个权限：UI 组件权限、API 访问权限（这个组件所访问的 api ）
从理论模型分析：功能 = UI 权限 + API 权限
从用户的角度看授权，进一步被简化成了：功能 = 权限