从壹开始前后端 [vue后台] 之二 || 完美实现 JWT 滑动授权刷新

缘起

哈喽大家周一好!不知道小伙伴们有没有学习呀,近来发现各种俱乐部搞起来了,啥时候群里小伙伴也搞一次分享会吧,好歹也是半千了(时间真快,还记得5个月前只有20多人),之前在上个公司,虽然也参与组织过几次活动,这个再说吧,毕竟都是五湖四海的小伙伴,不太好聚??。今天要说的内容很简单,但是个人感觉很实用,从文章标题就可见一斑:JWT的滑动授权,这个问题我被问了不下 n 次,从 6 个月前开始第一次写 JWT 授权,就有小伙伴陆陆续续在群里提问,说如何然这种无序化的 Token 令牌(不像 Session 那样,一直存在会话状态),达到滑动刷新,实现用户的无感知授权,我也一直在思考,大抵有以下一些思路:

1、token 失效后,直接跳转到登录页; // UE体验感贼差

2、将 JWT 、 用户标识 ( 如:id ) 、过期时间等令牌信息存到数据库,配合用户进行操作; // 额外的操作太多,连接数据库

3、同样的上边的这些信息放到 Redis 里,再配合缓存,也可以高效处理;// 虽然不操作数据库,但是变相破坏Token的无序性

4、前端通过 refresh_token 来刷新 access_token;// 本文要说明的,和这个类似的策略方法

5、等等其他

这些方法和策略我也一直和群里小伙伴讨论,但是却一直没有写文章,也一直没有真正的通过代码写出来,以前偷懒是因为只有后台 .net core 项目,后来自己又偷懒说只有博客项目,直观上不好实现,现在好了,终于在这段时间上线了后台管理系统,终于把这个问题提上了日程,那下边就开始今天的说明吧。

老规矩,还是先看效果(这篇文章比较简单,但是有一丢丢的绕,希望看的时候,可以有十多分钟的安静时间,不要着急,自己研究出来的永远比问出来的要高效的多):

故事背景:

当前 Token 将于 18:05:14 失效,以前的情况是,在失效后,直接跳转到登录页,但是现在不是了,

在 18:05:19 的时候,执行查询,我们重新对 Token 进行无缝刷新,然后自动重发请求并成功加载数据,是不是达到了你想要的目的?

那这个到底是如何实现的呢,复杂不复杂呢?如果是你想要的,请往下看 ??,保证每个人都能看懂,前提是你有 JWT 基础,至少用过。

一、我的设计思路是怎样的

1、传统的授权流程

传统的授权登录呢,很简单,也很直白,就是我们平时使用的,因为不像 session 那样,可以一直保持着状态,当我们的 Token 失效了以后,就只能重新获取一个新的 Token 令牌,这不仅仅是它的优点也是一个缺点,

优点就是可以支持分布式,多点式的访问,session 就不能实现分布式;

缺点当然也是显而易见,当其过期了,就无法续签,或者一直保持激活状态;

我们就只能重新获取一个,所以一般有的开发者就索性把 Token 的过期时间定的很长,比如一天,一周,甚至十天,只有用户在当前电脑上登录一次,以后就可以随心访问了,除非自己手动点击退出登录,说真的,这种情况我也在使用,因为我们公司的项目有一些是内部的前台项目,比如一个Tool,一个图表系统,或者一个简单的个人数据展示,一不怕被外网看到,不会被篡改,二没有公司其他人来使用我的电脑,我就定义了一个月的失效时间,平时就完全不用登录了,想想也是可以的。

但是,更多的是需要用户去实时登录的,相信大家也用过一直公网的管理后台,关闭浏览器或者一段时间不操作以后,就会提示需要我们重新登录,所以我们就会把 Token 的失效时间定义的很短暂,比如我的一些项目就是 30 分钟,或者一个小时,这样不仅更安全,而且也可以应对那些存在变化的,比如后台管理系统,当前用户的角色变了,总不能还用之前的令牌吧,所以短时的 Token 刷新还是很有必要的。

这样就会出现一个问题,如何实现滑动授权,就是在流程上,Token还是会失效,但是在用户体验 UE 上,实现无感操作,让用户在没有察觉的情况下,实现这个功能,你可以先停下来,想想如何设计,如果想好了,请继续往下看,看是否和你的思路一致。

2、实现滑动的授权流程

这两个流程图对比起来,不同点就在于虚线的问题,由之前的失效即跳转到登录页,多了一个选择——在用户活跃期内,通过旧的 token 换取新的 token 继续体系内循环,这样就达到了效果(这里还有一种,就是同时发放两个 token 到前端,一个是access_token,一个是 refresh_token,我做了等价处理,其实这两种是一样的)。

这样不仅能满足无缝刷新的问题,还能保持 Token 的无序性,那具体的如何在项目中使用呢,请往下继续看。

二、实现滑动的三步走

从上边的流程图中,我们可以看出来,其实要实现滑动刷新很简单,只需要我们在 Token 失效的时候,重新获取一个 token,并重新执行一个请求即可,所以我总结了以下三个步骤:

1、定义刷新时间戳

你一定会好奇为什么定义一个刷新时间,不知道你是否还记得上边我刚刚说到了,其实一般的做法是:每次登录,向前端丢两个 token,当我们的 access_token 失效的时候,就判断 refresh_token 是否有效,如果 refresh_token 有效,我们就把这个 refresh_token 带到资源服务器,换取新的 access_token,这样就实现了我们的目的。

但是我们不想这么操作,太麻烦,还需要生成两个,所以就人为的在前端定义了一个刷新时间点,只要在这个时间点内并且 token 失效了,我就用这个失效的 token 获取新的token:

在 Login.vue 页面中定义一个刷新时间:

 var token = data.token;
 _this.$store.commit("saveToken", token);// 保存 token

 var curTime = new Date();
 var expiredate = new Date(curTime.setSeconds(curTime.getSeconds() + data.expires_in)); // 定义过期时间
 _this.$store.commit("saveTokenExpire", expiredate); // 保存过期时间
 window.localStorage.refreshtime = expiredate; // 保存刷新时间,这里的和过期时间一致

在浏览器中查看两个时间:

2、当执行操作时更新刷新时间(重要)

 A:定义方法:

我在 api.js 文件中,定义了保存刷新时间的方法 saveRefreshtime() ,这个的作用主要是记录当前用户的操作活跃期,当在这个活跃期内,就可以滑动更新,如果超过了这个时期,就跳转到登录页:

export const saveRefreshtime = params => {

    let nowtime = new Date();
    let lastRefreshtime = window.localStorage.refreshtime ? new Date(window.localStorage.refreshtime) : new Date(-1);
    let expiretime = new Date(Date.parse(window.localStorage.TokenExpire))

    let refreshCount=1;//滑动系数
    if (lastRefreshtime >= nowtime) {
        lastRefreshtime=nowtime>expiretime ? nowtime:expiretime;
        lastRefreshtime.setMinutes(lastRefreshtime.getMinutes() + refreshCount);
        window.localStorage.refreshtime = lastRefreshtime;
    }else {
        window.localStorage.refreshtime = new Date(-1);
    }
};

上边的方法中,红色的是重要的两点:

1、滑动系数 refreshCount

这个是什么意思呢,就是你自定义的用户的停止活跃时间段,比如你想用户最大的休眠时间是20分钟,说句人话就是,用户可以最多20分钟内不进行操作,如果20分钟后,再操作,就跳转到登录页,如果20分钟内,继续操作,那继续更新时间,休眠时间还是以当前时间+20分钟。

2、最后刷新时间 lastRefreshtime

这个就是上边说到的,当用户操作的时候,实时更新最后的刷新时间,保证用户活跃时间一直有效,这里有一个重要的就是:

lastRefreshtime=nowtime>expiretime ? nowtime:expiretime;

我为什么要这么写呢,因为你考虑一下,如果 Token 的过期时间比你自己定义的刷新时间还长,举个栗子,你后台定义的 token 过期时间是30分钟,但是你的前端页面刷新时间是20分钟,当你登录后,30分钟内没有任何操作,再31分钟的时候,重新操作,token 肯定是无效了,但是很巧,你的刷新时间也是十分钟前,那就只能去登录页了,这样达不到刷新的目的,所以我经过大量测试,无论是token过期时间,还是页面刷新时间,只要取一个较大者就行,然后加上滑动系数,这样就能满足各种情况,不信你可以试试。

B:两处调用:

那现在既然定义了这个刷新方法,在哪里调用呢,我这里想到了两个地方,当然,你也可以根据自己的需要进行自定义设计,我的是:

1、在路由钩子里刷新; //在 router.js  的 router.beforeEach 调用方法 saveRefreshtime(),保证每次进行路由切换的时候,都激活用户活跃时间。

2、在 HttpRequest 钩子刷新;//在 api.js 的 axios.interceptors.request.use 中调用 saveRefreshtime() ,因为有可能用户长时间操作同一个页面,没有进行路由切换。

我这里就处理了这两个地方,无论是用户切换路由,还是在同一个路由的不同按钮操作,都能保证当前用户是在操作活跃期的,进而实现滑动的效果。

3、Token无效时,无缝获取新Token,并重新请求(核心)

现在就到了关键时刻了,定义好了刷新时间,那如何进行滑动效果呢?请先看下边代码,重点是红色的部分:

// http response 拦截器
axios.interceptors.response.use(
    response => {
        return response;
    },
    error => {
        if (error.response) {
            if (error.response.status == 401) {
                var curTime = new Date()
                var refreshtime = new Date(Date.parse(window.localStorage.refreshtime))                // 在用户操作的活跃期内
                if (window.localStorage.refreshtime && (curTime <= refreshtime)) {                    // 直接将整个请求 return 出去,不然的话,请求会晚于当前请求,无法达到刷新操作
                    return  refreshToken({token: window.localStorage.Token}).then((res) => {
                        if (res.success) {
                            Vue.prototype.$message({
                                message: ‘refreshToken success! loading data...‘,
                                type: ‘success‘
                            });

                            store.commit("saveToken", res.token);

                            var curTime = new Date();
                            var expiredate = new Date(curTime.setSeconds(curTime.getSeconds() + res.expires_in));
                            store.commit("saveTokenExpire", expiredate);

                            error.config.__isRetryRequest = true;
                            error.config.headers.Authorization = ‘Bearer ‘ + res.token;                            // error.config 包含了当前请求的所有信息
                            return axios(error.config);
                        } else {
                            // 刷新token失败 清除token信息并跳转到登录页面
                            ToLogin()
                        }
                    });
                } else {
                    // 返回 401,并且不知用户操作活跃期内 清除token信息并跳转到登录页面
                    ToLogin()
                }

            }
            // 403 无权限
            if (error.response.status == 403) {
                Vue.prototype.$message({
                    message: ‘失败!该操作无权限‘,
                    type: ‘error‘
                });
                return null;
            }
        }
        return ""; // 返回接口返回的错误信息
    }
);

其中要注意的是三点:

1、判断是否是在用户操作活跃期,如果不在,直接跳转登录页,反之,进行 refresh 操作;

2、return refreshToken ,这里是两个return 的第一个,需要将刷新token的网络请求返回过去,不然的话,刷新token的请求成功后,当前网络请求已经结束了,无法达到刷新的目的;

3、return axios(error.config) ,这里就是重新进行一次请求,特别是 error.config ,这个就是我们当前请求的全部信息。

效果如下:

好啦,JWT 滑动授权刷新就到这里已经完成了,是不是很简单。

三、实现滑动刷新的后端方法

1、Redis,控制 Token 颁发

除了这个前端方法以为,还有后端处理,设计思路也很简单,我就不多说了,简单说两句:

当用户登录的时候,生成 access_token ,我们把 token 存在 redis 缓存中,对应匹配用户标识,状态等,当用户修改了密码,或者当前用户的权限被超级管理修改的时候,把 redis 中的当前用户的token 也更新操作,等用户再次使用的时候,先判断当前用的 token 是否有效,然后再判断是否有权限,这样也能达到效果。如果过期了,还可以把新的token 放到 Header 中返回过去,不过这样的方法,还是需要配合前端操作,个人感觉还不如上边的方法。

如果有想尝试的小伙伴,可以自己尝试下,我简单提示一下,就是在后端项目的 PermissionHandler.cs 文件中,对当前 httpContext.Request.Headers["Authorization"] 进行获取 token 判断,至于怎么操作这里就不表了。

四、Github && Gitee

https://github.com/anjoy8/Blog.Admin 前端

https://github.com/anjoy8/Blog.Core 后端

-- ♥ -- ♥ -- ♥ -- ♥ -- ♥ -- ♥ --

原文地址:https://www.cnblogs.com/laozhang-is-phi/p/10462316.html

时间: 2024-10-30 09:55:28

从壹开始前后端 [vue后台] 之二 || 完美实现 JWT 滑动授权刷新的相关文章

从壹开始前后端分离【 .NET Core2.0 Api + Vue 3.0 + AOP + 分布式】框架之九 || 依赖注入IoC学习 + AOP界面编程初探

代码已上传Github,文末有地址 说接上文,上回说到了<从壹开始前后端分离[ .NET Core2.0 Api + Vue 2.0 + AOP + 分布式]框架之八 || API项目整体搭建 6.3 异步泛型+依赖注入初探>,后来的标题中,我把仓储两个字给去掉了,因为好像大家对这个模式很有不同的看法,嗯~可能还是我学艺不精,没有说到其中的好处,现在在学DDD领域驱动设计相关资料,有了好的灵感再给大家分享吧. 到目前为止我们的项目已经有了基本的雏形,后端其实已经可以搭建自己的接口列表了,框架已

从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 十七 ║Vue基础:给博客首页加花样(二)

回顾 今天来晚辣,给公司做了一个小项目,一个瀑布流+动态视频控制的DEMO,有需要的可以联系我,公司的项目就不对外展示了(一个后端程序员真的要干前端了哈哈哈). 书接上文,昨天正式的开始了Vue的代码的学习,简单的通过一些假的数据来展示了下个人博客的首页列表,不知道大家是否还记得昨天讲的什么,如果不太清楚呢,可以再回顾下<从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 十七 ║Vue基础:使用Vue.js 来画博客首页(一)>,我们主要说到了,Vue的核心语法是什么,MVVM

从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 二十三║Vue实战:Vuex 其实很简单

系列教程一目录:.netcore+vue 前后端分离 系列教程二目录:DDD领域驱动设计 系列教程三目录:Nuxt.js TiBug系统 系列教程四目录:VueAdmin 后台管理系统 系列教程五目录:IdentityServer4 授权服务器 本文梯子 前言 零.今天要完成实战1中的红色部分 一.常见的 Vue 表单提交是如何设计的? 1.表单.按钮等在一个组件内 2.按钮在父组件.表单在单独的子组件内 二.通过 $emit 修改父组件数据 1.在原来代码里 About.vue 修改成 For

从壹开始前后端分离【 .NET Core2.0 Api + Vue 2.0 + AOP + 分布式】框架之七 || API项目整体搭建 6.2 轻量级ORM

代码已上传Github,文末有地址 书接上文:<从壹开始前后端分离[ .NET Core2.0 Api + Vue 2.0 + AOP + 分布式]框架之六 || API项目整体搭建 6.1 仓储>,我们简单的对整体项目进行搭建,用到了项目中常见的仓储模式+面向接口编程,核心的一共是六层,当然你也可以根据自己的需求进行扩展,比如我在其他的项目中会用到Common层,当然我们这个项目接下来也会有,或者我还会添加Task层,主要是作为定时项目使用,我之前用的是Task Schedule,基本能满足

从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 十六 ║ Vue前篇:ES6初体验 &amp; 模块化

缘起 昨天说到了<从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 十五 ║ Vue前篇:JS对象&字面量&this>,通过总体来看,好像大家对这一块不是很感兴趣,嗯~~这一块确实挺枯燥的,不能直接拿来代码跑一下那种,不过还是得说下去,继续加油吧!如果大家对昨天的小demo练习的话,相信现在已经对JS的面向对象写法很熟悉了,如果嵌套字面量定义函数,如何使用this关键字指向.今天呢,主要说一下ES6中的一些特性技巧,然后简单说一下模块化的问题,好啦,开始今天的讲

从壹开始前后端分离 [ Vue2.0+.NET Core2.1] 二十一║Vue实战:开发环境搭建【详细版】

系列教程一目录:.netcore+vue 前后端分离 系列教程二目录:DDD领域驱动设计 系列教程三目录:Nuxt.js TiBug系统 系列教程四目录:VueAdmin 后台管理系统 系列教程五目录:IdentityServer4 授权服务器 本文梯子 缘起 零.今天要完成左下角红色的部分 A.Vue 常见的IDE —— 我是开发工具,干活的都是我 1.VsCode 2.Webstorm 3.Atom B.安装Nodejs环境 —— 我是运行环境,没我不行 C.安装 npm / cnpm ——

从壹开始前后端分离【 .NET Core2.0 Api + Vue 2.0 + AOP + 分布式】框架之六 || API项目整体搭建 6.1

书接上文:前几回文章中,我们花了三天的时间简单了解了下接口文档Swagger框架,已经完全解放了我们的以前的Word说明文档,并且可以在线进行调试,而且当项目开始之中,我们可以定义一些空的接口,或者可以返回假数据,这样真正达到了前后端不等待的缺陷,还是很不错的,当然,这离我说的前后端分离还是相差甚远,今天呢,我们就简单搭建下我们的项目架构. 本项目是我自己的一个真实项目,数据都是真实的,之前搭建过一个MVC + EF Code First的项目,本项目就是基于这个了,前一段时间我已经搭建起来了,

dotnet core webapi +vue 搭建前后端完全分离web架构(二)

前言 最近几年前后端分离架构大行其道,而且各种框架也是层出不穷.本文通过dotnetcore +vue 来介绍 前后端分离架构实战. 涉及的技术栈 服务端技术 mysql 本项目使用mysql 作为持久化层 orm dapper 短小精悍,被称为orm中的瑞士军刀.作者之前使用EF 比较多,总感觉 EF 对一些复杂查询需要原生sql支持的不是那么好,EF 生成sql 不好控制,涉及对性能要求比较高的地方,优化起来不够理想.作者在最近的几个项目中接触到dapper,它对原生sql查询支持的相当给力

前后端分离后台api接口框架探索

前言 很久没写文章了,今天有时间,把自己一直以来想说的,写出来,算是一种总结吧!  这篇文章主要说前后端分离模式下(也包括app开发),自己对后台框架和与前端交互的一些理解和看法.     前后端分离,一般传递json数据,对于出参,现在通用的做法是,包装一个响应类,里面包含code,msg,data三个属性,code代表状态码,msg是状态码对应的消息,data是返回的数据. 如  {"code":"10008","message":"