管理类型的系统，常常需要具有权限管理能力。
FDP架构对权限模块进行了非常好的抽象，与具体业务松耦合。所以权限模块是已经开发完成的。
权限管理核心的5张表
- 用户表
- 角色表
- 资源表(菜单表)
- 用户、 角色中间表
- 角色、 资源中间表
认证、授权
认证：通过“登录”知道用户是谁
授权：知道用户是谁后，为用户授予操作权限（从表中读出用户拥有的权限）
资源的分类
可以匿名访问，登录模块、图片验证码模块
登录后可访问，退出模块、首页模块
授权后可访问，业务模块
（权限管理重点工作区）
不可分配权限，如针对超级管理员专有权限
禁止访问，用于临时关闭某个模块
访问控制
基于角色的访问控制 和 基于资源的访问控制 要二选一，不可混用
基于角色的访问控制（ 不建议使用 ）
业务逻辑举例：如果A用户是B角色,则可以访问C资源。C资源需要B角色才可以访问。
不建议使用， 因业务逻辑代码中明确编写了角色，与角色耦合了，但角色又是可以增删改的。
所有当你的权限逻辑出现了“角色”判断就是不对的。
基于资源的访问控制（建议使用）
业务逻辑举例：如果A用户的授权列表中有C资源，则可以访问C资源。
建议使用，因为系统开发完成后，业务逻辑与资源都是“固定的”，能建立稳固的关系，是最佳实践。
权限管理的颗粒度
粗粒度、细粒度的权限控制。粗粒度是最常用的，已可满足大部分业务要求。
粗颗粒度的权限管理
可控制到模块级、方法级
例如，对用户模块的修改用户方法是否有操作权限、对栏目模块是否有权限进行CRUD。
细颗粒度的权限管理
可控制到表中的记录级
例如，A用户只能修改自己发布的文章(文章模块)，经理只能看本部门的文章(文章模块)。
真实业务举例：
为某集团开发了一个cms系统，由于集团规模大部门多，权限管理分的细。
cms系统有一个栏目模块，用栏目模块建立了A\B\C 3个栏目，1部门的员工可操作A栏目，2部门的员工可操作B栏目，3部门的员工可操作C栏目.
做到粗粒度的权限管理不能满足业务要求，要做到细粒度的。
A\B\C 是栏目表的3条记录，细粒度的权限就是记录级的权限。 实现起来要依靠写代码，目前无法抽象出来。
细粒度-数据权限的范围
公司部门的细粒度权限：所有数据、所在公司及以下数据、所在公司数据、所在部门及以下数据、所在部门数据、仅本人数据、按明细设置
商品分类的细粒度权限：查看某商品分类下的商品、查看某栏目分类的文章
机构的层级
集团、公司、部门、小组
一级、二级、三级、四级
国家级、省部级、厅局级(地厅级)、县处级、乡科级