权限系统表设计探讨

场景:

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.1 菜单的展示(jsp过滤掉)
1.2 超链接与按钮的展示(jsp过滤掉,或者通过对按钮增加attr,然后返回html页面时拦截.判断attr.再做处理.)
1.3 字段的展示不展示(后台逻辑代码控制)

1. ###后台权限严格控制

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>

如果什么不明白的地方,或者什么问题.私信我.