场景:
A用户只能访问 a b c资源 B用户只能访问abc资源 C用户只能访问abcde资源
最初的选择
最简单的权限设计 user 表 privilege表
然后再建一个user_privilege表 把 Aa Ab Ac ....对应起来.
优点:直观简单
缺点:脱离生活实际,生活中不可能每个人的权限不一样.肯定大多数人的权限是一个样的.就比如AB.所以这样设计造成了数据库的冗余.
权限5表:
既然AB的权限一样,那么是有相同身份地位的人才有可能有相同的权限,也就是我们生活中角色的概念.
- user
- role
- privilege
- user_role
- role_privilege
我们举个实际的例子.比如人员管理的一些权限.
新增人员 查看人员列表 查看人员详细信息 审批请假三个权限
人事主管 新增人员
查看人员列表
查看人员详细信息
审批请假
人事专员 新增人员
查看人员列表
查看人员详细信息
那么我们来看,其实在这里的体现就是部门+职位来判断角色
继续扩张:
- dept 比如销售 研发等
- postion 比如 经理 副经理 总经理 总监 一般员工等
- user 关联到dept postion
- role 关联到 dept postion
- privilege
- role_privilege
权限表如果一旦角色一旦拥有了人员管理的新增操作.那么肯定应该可以有查看的权限,而且不仅可以查看列表,还可以查看详情,所以权限大类无非增删改查.所以可以减少privilege中数据的量只需要人员管理的权限一条记录而在role_privilege中还需要新增4个字段来记录是否有增删改查的权限.
再演变:
如果新增一个功能,但是这个功能只能对某些个人开放.这部分人并不遵循常规的dept与postion来定义角色.
所以还是需要user_role这张表来处理.哪些并不是有dept与postion来决定的角色.
web如何做权限控制
- ###展示的权限控制
1.1 菜单的展示(jsp过滤掉)
1.2 超链接与按钮的展示(jsp过滤掉,或者通过对按钮增加attr,然后返回html页面时拦截.判断attr.再做处理.)
1.3 字段的展示不展示(后台逻辑代码控制)
- ###后台权限严格控制
2.1 url的访问权限控制(spring可以通过注解配置来实现)
2.2 内部方法互相调用的权限控制(spring的注解.当调用领一个有权限注解的方法时候.需要再验证一次)
2.3 代码内部业务权限(根据不同权限做不同的业务事情.比如)
WEB具体实现:
1.class的control中增加
@Controller
@RequestMapping("/user")
public class UserController{
//方法add中增加
@privilege(code="user.add")
@RequestMapping(value = "/add", method = RequestMethod.GET)
@ResponseBody
public User add(){}
}
所以出现了三个对应关系
方法 请求url 权限码
2.menu增加权限控制
在menu表中直接增加一个权限码column
3.页面按钮增加权限控制
<button value="新增" privilegeCode="user.add"></button>
如果什么不明白的地方,或者什么问题.私信我.