使用背景:不同角色访问页面权限控制
说到权限实现方案,个人觉得先看前后端实现架构。
举个例子,项目架构如下:
浏览器 -> web服务器 -> 网关 -> 后台服务
方案1,前端控制页面访问权限,后端不做接口权限控制。 - 绕过前台可直接访问接口,前端权限控制存在的安全隐患。
方案2,前端不做页面控制,有后端进行权限控制。- 后端进行权限控制,基本上能避免绕过前台接口调用接口的问题,但是能看到不能访问一些菜单,给用户的体验不太好。
方案3,前后台都做页面权限访问控制。- 前后都做权限控制,这个相对比较完美的方案。
最终采用哪一种需要根据项目实际情况而定,这里根据方案3做一下自己项目过程中的分析总结,请大家共勉。
从策略上来说根据是否需要在网关做统一的接口权限控制分情况:
一、网关统一做url鉴权;
优点:网关处进行URL鉴权,代码简洁清晰,不需要在每个业务接口总进行权限适配,代码相对比较简单。
缺点:配置比较繁琐,根据角色找到接口url进行配置。假设每个角色分配对应数据接口的权限模型列表如下:
角色 | 页面 | 接口 |
A | 页面A | 接口1 |
B | 页面B | 接口1 接口2 |
C | 页面C | 接口3 |
网关实现核心思路:
登录是获取用户权限模板URL列表,定义filter过滤器,获取当前请求url,在权限列表中判断访问接口URL路径是否在用户权限列表中,如果在则URL鉴权通过,否则鉴权失败返回鉴权失败信息。
二、不在网关做统一的URL鉴权,而是在接口中做URL鉴权。
前后台权限点定义模型:
项目列表 | |||||
页签 | 数据 | 操作 | |||
名称 | 字符串 | 名称 | 字符串 | 名称 | 字符串 |
在途项目 | service-som:project:underway | 全国 | service-som:project:view_all(前端) service-som:project-info:view(后端) | 推进项目 | service-som:project:promote(前端) service-som:project-info:cornerstone_manage(后端) |
区域 | service-som:project:view_region(前端) service-som:project-info:view(后端) | 项目暂停 | service-som:project:pause(前端) service-som:project-info:suspend(后端) |
根据角色进行勾选不同的权限点:
前后端在获取用户权限列表之后:通过判断用户权限是否包括某个权限点,有该权限点则鉴权通过,否则鉴权失败。