项目开发中,修改成功密码后,会弹框提示用户重新登陆,然后用户点击确定后,前端请求登出接口,清空本地存储,跳转登录页面。
与此同时,项目中有个轮询接口,在超时或者用户密码修改成功,原token失效的情况下,会返回302状态码,跳转登录页面。
那么如何保证修改密码成功后,不会因为轮询接口返回302重定向登录页面,导致密码修改成功后的逻辑没有来得及执行下去。
我们可以在修改密码成功后,在本地存储一个key,当有这个key存储的时候,不去请求轮询接口。然后在密码修改成功后的逻辑都顺利执行完的时候,删除这个本地存储的key。
但是这个主项目还引入了其他子项目,其他子项目也有轮询接口,如果每增加一个子项目,我们都像这个主项目的框架一样,去根据本地存储key判断是否轮询,来避免因为修改密码后用户token失效提前跳转登录页面,那么拓展性就很差。
我们的设计是:
将返回302状态码的跳转登录地址存储在contextpath字段中,而不是location字段中。
这样就使得浏览器无法实现自动重定向,因为浏览器是去取location字段进行跳转的,如果location字段缺失,那么浏览器是无法自行实现重定向的。
我们只能在前端的响应拦截器里去手动实现重定向,也就是手动从响应头中获取contextpath字段的重定向地址,调用window.location.href进行重定向。
我们将重定向的能力交予主项目框架,其他子项目没有重定向的能力。
子项目不对302做特殊处理,那么子项目即便轮询接口报错302,也不会进行重定向。
而主项目框架,对302进行手动重定向,保证了超时的时候会重新登录,又结合了本地存储的key,保证了修改密码后,不去请求轮询接口,不让轮询接口302重定向影响到修改密码成功后前端逻辑的执行。
这样一来,子项目拓展性良好,也保证了超时重新登录的处理和修改密码模块的顺利执行。