前端（vue）登录权限验证 |
您所在的位置：网站首页 › 前端实现登录验证码检验插件怎么设置 › 前端（vue）登录权限验证 |
|
前言
代码如同爬山，到山顶有很多条路，很难说哪条是最好，各有各的特点。
业务场景大致分类
1.登录权限验证：部分页面没有登录不允许访问2.角色验证：在登录权限的基础之上加角色权限的验证，比如同一个页面两种角色权限看到展示内容被板块不同。
具体做法
首先可以肯定的是，无论是那种权限验证，完成的方法有很多种，各有各的特点吧。
我就拿vue来举例吧 1.仅是页面访问权限验证 1.1 利用路由来做判断，比如在全局路由守卫(beforeEach)中去完成一些验证操作 beforeEach //这里可以设置白名单，例如当home页面你不需要限制。 const WhiteList = ['login','home'] router.beforeEach((to, from, next) => { if(!WhiteList.includes(to.name)){ //在本地存储中获取token const token = window.localStorage.getItem("token") //token有值则用户已经登录，没有的话肯定就是还没登录 if(!token){ //没有登录则跳转到登录页面,fullPath不清楚的话可以去看一下vue-router的文档 next({ path:"/login", query:{ redirect:to.fullPath } }) } } next() }) login.vuelogin页面肯定是做登录的操作，这里我就只示例一下登录接口请求成功后的回调函数中的基本操作 function then(res){ //接受重定向过来传递的参数。这里有两种可能，1.是用户直接到login页面，2.是从其他页面跳转过来 const redirect = this.$route.query.redirect //实际业务场景中肯定不止token，还会有更多的信息，我就只写token了。 window.localStorage.setItem('token',res.userData.token) if(redirect){ //这种是从其他页面过来的情况，回到原页面 this.$router.replace({ path:redirect }) }else{//用户直接登录login的情况,例如登录成功后到home页面去，具体的看实际业务需求 this.$router.replace({ path:"/home" }) } }大致就是这样吧，当然如果业务逻辑复杂的话，这里可以根据具体的业务逻辑需求再细致化。 好处 相比较使用ajax中来做校验，减少了http通信的消耗权限不足时，在进入页面之前就能将用户阻拦。 缺点 每次路由跳转都要进行判断，假如项目中有20个页面，但是只有3个页面需要权限验证，那么这样是不是感觉有点大动干戈 解决方案 其实这个问题解决起来也很简单，只需要将全局前置守卫(beforeEach)换成路由独享守卫(beforeEnter)即可。但是这就要在多个路由配置中都要写一个beforeEnter，利弊自己权衡。 1.2 通过在axios请求和响应拦截器中验证 首先我们要清楚在我们前端和后端接口通信的时候，要将token放到请求头的 Authorization 中 ，一同发给后台的。这个操作一般在请求拦截器中完成。 axios请求拦截器在请求拦截器中将token放到请求头中 axios.interceptors.request.use((config)=>{ let token = window.localStorage.getItem('token') if(token){ config.headers.Authorization = token } return config },(error)=>{ return Promise.reject(error) }) axios响应拦截器后台判断接口是否需要权限，或者请求头中有没有token来决定是返回正常数据，还是返回 ‘401’ axios.interceptors.response.use((res)=>{ //这里做请求成功后的操作，具体看你架构怎么设计的，可以对后台返回的数据进行进一步处理 return response },(error)=>{ //这里是请求失败的回调 //我们只需要判断是 ‘401’的话，就让其到登录页面 if(error.response.status == '401'){ //要知道还有登录过期的情况，后台也是返回 ‘401’，所以这里就要有如果是这种情况的处理 window.localStorage.removeItem('token') //别忘了import引入router就行 router.replace({ path:'/login', query:{ redirect:router.app.$router.funllPath } }) } }) 中心思想 其实是将权限验证的权力交由后端处理，后端处理起来也很方便，比如后端使用基于ssm架构的话，spring官方就有对于接口权限处理的配置前端我们只是对于后端的反馈做进一步处理，相当于后端是法官，前端是侩子手。 需要注意的地方需要和后端沟通好，因为需要给一些接口设置白名单，不可能所有的接口都需要token验证 这样的业务逻辑设计一定要有清晰的思路， - 1.哪些页面会一进来就有接口请求， - 2.哪些页面需要用户进行一些操作才会发生接口请求； - 3.甚至有些页面至始至终都不会有接口请求 那么像 第三种情况页面 在业务需求上是不是允许游客访问然后在游客操作的时候再提醒登录？ 像 第二种情况页面 是不是在业务需求上就不需要做权限验证？ 这些都要考虑清楚利弊，其实不存在哪种方法更好，只是它可能更适合你的业务需求。 2.角色页面权限验证 简单描述：一般较为复杂的项目，可能会有更深层的角色验证，最常见的是报表类或者后台管理系统的项目， 举个例子， 部门主管登录和普通员工登录，同一个项目，有可能有的页面部门主管就可以访问，而普通员工就无法访问。同一个页面，部门主管就会比普通员工看到的板块多。 角色分类 未登录（游客）已登录（不同角色权限） 开始开发之前的程序设计像这种比较复杂的权限验证，需要后端要将什么角色能够访问什么页面以及什么板块配置在数据库中， 简单来说就是，数据库中 有这么一个表，专门来存储这种角色权限配置的，至于为什么这么做应该就不需要我在此进行赘述了吧 设计 页面（模块）描述（比如”首页“）页面路径 （比如 login） 简单来说就是这样，将其整理成文档，大部分公司会有完整的类似这样的流程，肯定会比这个更详细。 开发这里我们做权限验证可以通过路由的方式，也可以通过axios拦截器得方式完成。 路由的话： 可以通过路由守卫的方式，在判断token的基础上再加上对于角色权限的判断axios拦截器： 可以由前端再将角色信息放到接口参数返还给后台。也可以由后台再登录后将用户信息放到sesstion中，后台再做权限验证返回 “401”.注意：利用接口做权限验证，要考虑公用接口。 一个接口可能在有权限和无权限的页面都有调用。那么我们可以由前端将路由路径信息也返回给后台，根据页面加角色综合判断。 3.角色模块权限验证 描述这种是在页面的基础上加上同一个页面内，对于不同板块的权限验证。 vue组件化这里就不得不提到vue的组件化开发；如果大家有过vue开发经验，那么相信肯定不会对组件这个概念陌生。 但是实际上，使用vue和组件化开发是两个概念，只能说vue能够完成组件化开发。但是也有一些人只是用了vue，但是却没有利用好组件这个东西，大致分为两类。 1.将多个页面有相似的模块提出来封装成公共组件，然后去复用这个组件，传递不同的数据参数，使其呈现不同的内容 2.页面中几乎全部被封装成了组件，然后页面就像搭积木一样，由多个组件组合而成。 两者各有各的好处， 第二种灵活性高，可扩展性高，但是很致命的一个问题就是对于vue的熟练度要有一定的要求，并且如果更换开发人员，那么单单是熟悉项目就需要花费巨大的精力，整个项目如同一张蜘蛛网，虽然有理可循，但是又错综复杂。第一种可维护度高，新来的同事可能仅仅需要一天，甚至半天的事件就可以上手写功能，甚至修改bug。虽然一个页面大部分内容可能都集中在同一个vue文件中，代码看起来可能比较冗余，但是带来的一个很直观的优点就是我可以很快速且方便的理清楚这个页面的业务逻辑。 设计角色模块权限验证，就需要组件化开发。 页面描述页面路径信息组件描述组件命名 中心思想页面由多个组件组成，我们通过动态组件 （component）的方式来加载组件，至于加载那些组件，则由后台接口返回的信息来控制；不会有接口请求的页面，像这种情况跟着开发设计文档的要求走就可以了。 举例 开发前的设计：home页面；共有A，B，C三个组件；其中B组件模块只有经理可以访问登录接口中后台返回信息：pageData : { home : [ ‘A’ , ‘C’ ] }将信息存储在vuex中home页面：在vuex中取到页面模块信息，然后通过动态组件（component）来将A，C加载出来。 注意一定要注意对于样式的设计，多一个，少一个模块，页面布局会不会乱掉。这里可能对css样式的熟练度有点要求。 整体总结我代码的演示比较少，第一是我写的比较简单，不一定符合你的业务需求。第二就是无论是什么，一定要有自己的理解，并且灵活运用。不一定就要用哪种方式，有时候甚至可以参杂使用。 这只是我的个人的一些见解，不一定就好。当然肯定还有其他的方式，对于我们自己没有尝试过的方法，取其精华，去其糟粕才是王道。 最终希望大家能够明白一个道理。你认可的开发模式（设计模式。。。）不一定就是最好的，只是你比较认可它罢了，别人的也并非一文不值。 |
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |
| CopyRight 2018-2019 实验室设备网 版权所有 win10的实时保护怎么永久关闭 |