、用户中心等)
文章目录
- 表
- 用户表
- 角色表
- 菜单表
- 关系表-角色菜单表
- 关系表-人员角色关系表
- 数据权限的管理
- 角色
- 角色新增
- 角色删除
- 角色修改
- 解绑用户
- 角色菜单
- 用户
- 用户新增
- 用户删除
- 用户编辑
- 用户查询(不涉及权限联动，略)
- 其他
- web端和h5端的权限过滤
- 效率问题
权限系统(用户中心)是一套核心的系统，有很多技巧和套路。
表
用户表
CREATETABLE`t_user`(`id`int(11)NOTNULL,`username`varchar(255)NOTNULL,`password`varchar(255)NOTNULL,PRIMARYKEY(`id`),UNIQUEKEY`username_unique`(`username`))角色表
t_role
菜单表
t_resource
关系表-角色菜单表
t_role_resource
关系表-人员角色关系表
t_user_role_authz
数据权限的管理
如果只涉及到本人数据，和本机构数据，那么不用建表，通过逻辑就能够控制。
如果要自定义机构数据，需要建表。而且比较麻烦，只能以平面的方式展示。
这里有点麻烦，例如有1万个用户，1000家机构，平面展示，就是1000万条数据。 有什么好的方法么?
微博中就是以这种平面式设计的，但是那么多用户肯定分区了，否则性能一定会很差。
角色
角色主要是和功能菜单建立关系。
角色新增
1、角色表新增记录或编辑信息。
2、角色菜单表添加记录(可多条)。
3、auth关系表无需操作。(因为这里还不涉及到人)
角色删除
1、角色表删除。
2、角色菜单表删除对应信息。
3、auth关系表删除该角色对应信息。
角色修改
1、角色表新增记录或编辑信息。
2、角色和菜单表联动。
3、auth关系表需要操作，角色添加菜单不用操作此表，但是去掉菜单需要操作此表。auth关系表去掉该(角色不再绑定的菜单)。 # 这一步操作可以省略掉。
重点肯定是第二步。
见过比较好的实践：
点编辑，全量菜单，根据已授权的标记为1。
点保存，已标记的全都传给后台。删除该角色下所有菜单，再新增传过去的即可。
解绑用户
这个功能也不多余，某个角色想去掉某个用户，难道只能到用户编辑里面吗?
当然不是，从角色这里应该直接可以。
auth关系表去掉该(角色+用户)的信息即可。
角色菜单
这个表看上去有点鸡肋，实际很有作用。
1、编辑角色菜单。
2、给用户授权时，
用户
单表操作没什么说的，主要是权限相关。
用户新增
1、用户表信息新增。
2、配置角色(至少一个默认角色，否则啥也看不到)。
3、auth关系表联动。
用户删除
1、删除用户表信息。
2、删除auth关系表该用户信息。
用户编辑
1、用户表信息修改。
2、auth关系表联动。例如角色的增减及机构的增减。
用户查询(不涉及权限联动，略)
其他
web端和h5端的权限过滤
之前这个问题想破脑袋，因为cookie不够优雅，而且代码乱糟糟。
后来经历过多个项目，是有现成的套路的。
比较好的方案是filter，
ignore-path-patterns # 忽略的地址
include-path-patterns # 包含的地址
当然也会有默认规则。
忽略的地址不拦截，例如/interface接口默认不拦截。
那么拦截到以后如何校验权限呢?
很简单，将token发送给用户中心单点登录校验。
推荐做成可配置的形式。
sso.url=单点地址sso.key=单点key这样就实现了拦截。
效率问题
之前用过的用户中心卡的要死，后来经过了一大波优化，速度快了很多，想知道是如何优化的。
这里要扣操作细节。
例如：
人员编辑，100个角色1000家机构，从第99个角色中去掉第998个机构的数据。
如何快速的落到库里。
