数据权限的设计与实现

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/hchaoyangming/article/details/50223027
最近手上的web项目需要做权限控制,努力了解下,做如下笔记
1.权限分为菜单权限,操作权限,数据权限,
菜单权限即不同用户能够看到的菜单按钮不同,如系统管理员能看到系统管理,用户管理等菜单,而普通用户是看不到这些管理菜单的。
操作权限即为不同用户能够对列表进行的操作权限,即增删改查等功能。
数据权限即不同用户能够看到的列表数据不同,如开发部员工只能看到开发部的所有日志列表,而总经理能够看到所有部门的日志列表。
2.各种权限的设计,
基本数据表有用户表user,角色表role,用户-角色表user_role,权限表function,角色权限表role_function,因为用户与角色,角色与权限都是多对多关系,需要中间表,
以上就可以实现简单的菜单权限控制。我们这里增加了操作权限表operation,数据权限表datarule。
表operation和datarule中都有function id字段,因为操作权限和数据权限都是依赖菜单权限而来的。并且,角色权限表中包含有id,roleid,functionid,operationid,dataruleid 5个字段。什么,角色权限表没看懂?其中一个roleid对应多个functionid的多个操作权限和数据权限,所以我们这里将每条记录里operationid,dataruleid用逗号隔开,表示该角色对该权限的各操作权限和数据权限。这下懂了吧。改天截图。
甚至还有部门表org,用户部门表user_org,角色部门表role_org,部门与用户,部门与角色都是多对多关系,一般情况下,有部门与用户关联就够了。
3.实现
这里说说数据权限的控制,我的项目数据权限控制比较简单,例如,各部门只能看他和他的下级部门的订单列表(order),
配置数据权限,如规则 org_code in #{org_code},系统后台必须查出该用户部门及子部门的所有编号。
当用户登录系统,且该用户对于的角色已经配置了订单菜单的操作权限和数据权限,这时系统会有session记录当前用户的各种信息,包括用户名和所在部门编号,
根据用户角色查询出该用户的所有权限,我们可以把所有权限保存在session中,key-value形式,以菜单url作为key,将对于的数据权限sql作为value,每当用户进入相应的权限菜单列表,就会检查session中是否存在数据权限,存在则拼接sql过滤,如org_code in ('id1','id2');

ok!
展开阅读全文

没有更多推荐了,返回首页