权限管理的一点思考

需求说明

不同的项目对于权限管理的需求也不同。以上海市人社管理系统为例，权限管理主要管理的是不同单位与不同职级的工作人员所能够操作的功能限制。可以通过组权限进行以单位为基准的权限管理，少部分根据职级的再进行单独管理（需求量比较小，不成规模体系，如主管单位操作基层单位功能），再将个人权限与组权限挂钩。

 

详细设计

1. 创建功能：基本信息，如所属模块、页面路径、所属菜单等

2. 创建组：组别不同，访问权限不同

3. 创建用户：用户所属单位（级别）不同，组别不同，如根据省市/区县/街道设置组别

4. 创建组与权限关联：每个组所关联的功能都有所不同，即权限不同

5. 创建用户与组关联：系统根据组别赋权（方式：返回无权限、加载限定功能等）

6. 创建用户与权限关联：系统根据用户赋权，通常是组权限和用户权限联表查，开发者通常用来赋全部权限

 

实现方式

实现的方式有很多种，主要分前后端，至于是前端卡口还是后端卡口看业务，比如单位分级别，省市的，区的，街道的，每个级别的权限都不同，这就意味着可以操作的范围不同。

如果说能明显从id的设置看出来，比如00打头是省市的，那么就前端卡，但实际上后端也可以卡，就是一样的判断放后端。如果卡口放前端，那么肯定权限相关的字段要能获取到，比如直接放在session里面（登录的时候），这样就能卡到权限了。

再打个比方，如果业务复杂一点，比如有一个功能是数据的查询统计，省市获取下级单位的汇总数据，区单位获取街道的汇总数据，这个肯定也是权限管理的一部分，因为你要判断权限再去做统计，那么这个情况下，前端还是后端？那就看在你的系统里，哪个更便利且更利于系统的开发维护。

和朋友也讨论过这个问题，他提出AOP的思想，比如每次请求判断用户权限，决定返回的页面，也可以，但如果在功能重合性较多的项目中，区分主页获取是更简单直接省系统消耗的方式吧。

 

权限配置

日常开发环境，如svn的权限、oracle库表的访问读写权限、linux文件权限等，归根结底也是从开发需求发展而来，逐渐演变为通过修改属性配置就可以改变操作范围的程度。