权限系统表设计探讨

场景:

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 postionrole 关联到 dept postionprivilegerole_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>

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