概念
笔者认为WEB系统权限应归纳为功能权限，数据权限（行、列）
- 功能权限：即菜单、按钮、超链接等，控制用户能否访问该资源，通常会将功能权限进行打包，用角色来进行分配；
- 数据权限：
- 行数据权限：即张三能看到A部门的信息，李四能看到B部门的信息，王五能看到A和B部门的信息，和功能权限一样都是用于控制资源的获取，不同点在于数据权限能更加精细化的进行资源把控，功能权限控制能否接触到资源，即返回yes或者no；数据权限控制接触资源的多少，可能没有返回数据，可能返回一部分，也可能是全部；
- 列数据权限：即张三能看到订单表格信息的5列，李四能看到4列，王五能看到6列，列权限是对资源信息的纵向切割，行权限对资源信息的横向切割。
二者共同构建出应用系统的权限模型，接下来本文详细描述下列权限的设计理念。
理念
列权限的设计应该思考以下几个特质：
-
非侵入性我们希望数据权限的设计应该是非侵入式的，希望开发人员在编码过程中不需要有字段权限的概念，让开发人员更多的关注业务，而不是时刻思考这个功能如何进行字段权限的实现，待系统开发完后，引入组件即可使用； -
扩展性我们希望字段权限的设计是可以后期在线可配置的，而不是编码过程中写死的，即开发过程不需要进行列权限处理，而上线后通过页面进行配置，即可轻松实现，同时不仅仅满足数据列的清除，也能支持脱敏、加密、混淆等多种业务场景，同时支持重写采取自定义处理； -
容错性应用系统的稳定性不应该受到字段权限设计的干扰，即列权限模块出问题了，不应该影响到业务系统，实现优雅降级； -
兼容性列权限的设计不应该只能适用于新系统，对老系统也能够实现插拔式的支持，且不用更改以前任何业务逻辑； -
便捷性设计应该借鉴spring boot starter 思想，进行可插拔式，免配置的使用，满足开箱即用，既有默认实现，又有重写覆盖的功能； -
通用性列权限的设计满足通用性、普适性，适用于多种类型的系统、多种应用；
实现思路
-
动态SQL拼接笔者认为该方案存在侵入性，扩展性，容错性，复用性上均存在较大缺陷，即开发过程中需要关注列权限有哪些，sql的编写与列权限强耦合，上层业务逻辑调用时，由于根据权限查询动态列，可能导致某些重要字段被过滤，导致业务层报空指针，且处理脱敏，过滤极为复杂，不建议使用。 -
数据拦截该方案的理念是在整个业务逻辑处理完后，进行对象字段的处理，从而达到字段权限控制的目的
笔者认为在序列化时处理是最佳时机，此时整个业务逻辑、异常逻辑都已经执行完毕，此时根据配置的字段信息，用反射对VO对象的字段进行处理
实现流程
数据库设计
列权限配置表两张column_permission、column_handler；
- column_permission表的职责负责存储哪个资源者对哪个url具有操作权限。
- column_handler 是与column_permission进行关联的表。前者和它是一对多的关系，它的职责是负责存储具体这个url所返回的资源对哪些字段做哪些处理
column_permission：
| id | resources | url |
|---|---|---|
| 1 | 62222 | /api/order/query |
| 2 | 张三 | /api/order/report |
| 3 | admin | /api/user/list |
| 4 | 身份证号1 | /api/user/query |
resources : 资源拥有者，资源者拥有我们定义为resources，既可以是用户id、用户姓名、也可以是角色、权限组，具体是什么由业务需求决定
url ：需要处理的资源，思前想后，我觉得还是用url较好，前后端请求是基于接口实现的，粗细度放在接口是比较合理的，之前思考过前端传需要加载的资源表等，但有安全性问题。
column_handler ：
| id | notes | process_column | processor | localtion_path | column_permission_id |
|---|---|---|---|---|---|
| 1 | 姓名 | name | 1(加密) | order_id | user.name |
| 2 | 身份证号码 | id_card | 2(脱敏) | id_card | |
| 3 | 性别 | sex | 3(抹去) | sex | |
| 4 | 手机号 | phone | 4(混淆 ) | phone |
notes: 中文注释，这个字段需要和页面表格或者详情的属性中文一致，给用户感知哪个字段做了什么处理
process_column ：需要处理的字段，和对应的pojo/DTO/DO/VO一致
processor ：处理器 1加密 2脱敏 3清除 4混淆 ；支持扩展；建议开发实现用策略模式
localtion_path：这个字段很重要，但是比较难理解，详情页返回的对象可能是嵌套的，需要处理的字段在N+M层（N等于当前对象层，M>=0）；如果不要这个字段，怎么才能找到，需要反射一个个去遍历，而加了这个字段之后，直接可以定位到，类似规则匹配
column_permission_id：上一张表的主键，方便一对多查询
列权限——初始化
笔者建议在登录认证成功后，进行列权限的初始化，获取字段权限表数据，放入缓存，流程和缓存结构如图
初始化.png
列权限——运行
以订单列表查询为例，具体流程如下图，处理器可以使用策略模式来实现，同时在处理器类型，和具体某一类型的实现上支持重写，达到扩展的目的
运行.png
列权限——配置
关于column_permission、column_handler表中数据的插入方式，可以采用功能权限的集中式配置，即数据权限的配置界面与功能权限放在一起配置
本文着重描写列权限设计的思想，具体祥设参考
通用数据权限设计——列权限（二）
