权限系统在前端应用中的处理方案

前端而言，涉及到权限的都是根据服务端返回的信息来确定哪些可以操作，哪些无权限浏览等，但是前 端完全报漏在用户端的特性，根据url来定位⻚面应用，若路由写死在程序内，那么只要知道路由链接， 那就可以去访问，那样就无法达到权限限制的作用;所以将路由也设计成服务器下发的机制，动态注册 的形式，同时生成相应的菜单。

和服务端定义好返回的内容，有的地址，组件，菜单名称，权限key等

{
    // ...
    rightKey: '34276fb093160d8ec8d6c6b2' // {1} 权限key
    rightName: '主播所属工会迁移功能' //{2}权限描述 在前端没有作用，后期可能会去掉 
    uri: '/unionList,,zbMOVE' //{3} 权限路由以及配置
    webRemark: '' //{4}菜单显示
    //...
}

主要用到了权限接口里这几个参数; {1} 是权限的 key，主要用作功能操作的限制，验证是否有此权限 {2} 权限的描述，用于前后端沟通使用 {3} uri 是权限路由以及操作的区分，使用英文逗号 , 来区分分别代表 /url路由[route],使用的组件名 [components],纯操作功能的描述[action] ，若是组件名在路由同时都是指向 pages 下的同一个组件,那 么是可以省略的，一旦有操作功能描述，那么约定为此权限只生效为为此⻚面内的操作功能权限，且该 路由不会记录在 router 内

{4} 纯前端使用，只是用于菜单的展示，支持多个层级，例如 工会审核/主播审核 这样会把 uri 放在放在 工会审核下面的主播审核⻚面上，且会作废工会审核上的 uri;为空时只是展示路由内⻚。支持排序，每 个菜单名字后拼接 : 添加优先级;默认时 99，0 是优先级最高的;依次升序优先级降序排列，例如 工会 审核:8/主播审核:2 ,优先级只是作用于兄弟节点。

根据各个参数的意义，程序会在获取该用户在该项目下的权限时，会进行路由和菜单的预处理，把权限 列表处理为路由和菜单能用的数据结构，之后再进行注册和渲染菜单。

vue项目中使用

在对接权限系统时会涉及到登录，获取权限以及解析权限为路由和菜单，无法定位路由或者获取失败时直接显示404⻚面。

对接权限系统统一登录

在对接权限的时候需要调用权限系统的统一登录，为了避免⻚面来回跳转，影响体验，使用iframe来加 载权限系统的登录⻚面，登录⻚面登录成功后会回调对接权限的项目的⻚面，再通过回调⻚面解析 code，去登录，之后把登录状态同步到iframe外部的环境中，由于iframe内外是同一个项目，所以不存 在iframe内外的操作跨域的问题;

解析路由和菜单

根据权限参数的意义解析成一组菜单的结构，路由的结构和权限key的结构，菜单结构将用在通用的菜单 组件上;路由结构将使用vue-router的内置方法 this.$router.addRoutes(routers) 进行动态注册路 由;

而对应的权限key结构将用在自定义指令 v-auth2=‘key’ 和注入的 this.auth2(key) 方法中使用来判 断是否有某个key的权限;

为了容易把权限系统接入项目，将这些程序包装为为一个js包，默认报漏一个用来设置权限某块的方法

export default function InitPermission (psmStr) { 
    psm = psmStr
    return { permission }
}

该方法返回一个store的module，直接放在 store.js 使用即可

import InitPermission from '@lib/mis/permission' 
export default new Vuex.Store({
    modules: InitPermission('9.2.3') 
})