一对一直播系统源码,后台管理系统权限控制方案
纯前端控制
前端写死配置文件,通过用户角色信息判断是否有权限。
例如
const anth = { 'admin': { //路由权限,如果路由权限为false/undefined则整个页面无权限 // 如果路由权限为true,则拥有全部路由下操作的权限 '/home': true, '/base/data': true, }, 'developer': { '/home': { 'getList': true, // 获取列表权限 'search': true, // 搜索权限 'submit': false, // 提交权限 'edit': false, // 编辑权限 .... } }, 'pd': { } ... }
上面简单书写了一下前端配置的模板。
上面这段配置表示
一对一直播系统源码的admin用户,拥有/home路由、/base/data路由的访问权限及页面所有操作权限。
developer用户,拥有/home路由,及/home页面下获取列表、搜索,没有提交、编辑权限。
pd用户无任何权限。
优点
纯前端控制,每次修改一对一直播系统源码的前端直接发布就好了。
缺点
被抓包会直接暴露所有权限信息
可以通过代理的方式,强行让用户获得页面的权限
无法针对一对一直播系统源码的单个用户进行权限配置,只能针对用户类型配置权限
前后端分别控制
还是上面内个文件,只不过由后端储存,并且返回的信息只有当前角色的信息
例如我现在的角色为developer那我拿到的信息就是↓
{ '/home': { 'getList': true, // 获取列表权限 'search': true, // 搜索权限 'submit': false, // 提交权限 'edit': false, // 编辑权限 } }
优点
一对一直播系统源码后端控制权限的返回,用户并不能拿到所有权限点的信息,相对安全
可以动态的给用户添加/修改/删除权限信息(之前纯前端的需要前端发布)
缺点
同样会被代理克制,劫持后返回所有权限,前端同样拦不住(因为前端拿到的是假的权限数据)
每次新增权限点的时候,需要一对一直播系统源码前后端一起发布
权限配置升级版
先确认一下权限是什么,权限就是用户可以进行的每一个操作,都需要校验他能否进行操作。
对应到页面,权限大概分为两个类型,一种是菜单权限(路由/页面访问权限),一种是功能点权限。
菜单权限可以由权限点进行绑定。
页面访问权限由前端来控制,是因为目前大多数前端页面都是SPA(单页面应用),后端不接管页面的访问权限(只有一个index)。
后端可以通过接口返回用户拥有的菜单权限,直接返回给前端,前端覆盖掉router的配置,让用户只能访问他有权限的页面。
操作权限也由另一个接口返回,数据格式如下
{ "home_get_list": 1, "home_search": 1, "home_submit": 0, }
前端配置的时候,提前预埋好权限点,然后对后端返回的权限数据进行判断。例如:
const TestAuth = () => { const onClick = () => { //判断提交权限 if(!globalAuth.home_submit){ //没有权限 message.error('没有提交权限'); return; } // 提交逻辑 ...... } return <Button onClick={onClick}>提交</Button> }
当然也可以直接判断没有该权限直接不展示提交按钮
const TestAuth = () => { const onClick = () => { // 提交逻辑 } // 有home_submit权限才渲染提交button return globalAuth.home_submit && <Button onClick={onClick}>提交</Button> }
总结
纯前端判断权限肯定是不可取的。前后端一起干才是硬道理。
一对一直播系统源码前端并不能真正的阻拦用户,就像用postman直接发请求一样,不通过前端的方式,直接和后端交互。
所以后端每个接口一定会做权限判断的。
以上就是一对一直播系统源码,后台管理系统权限控制方案, 更多内容欢迎关注之后的文章