修改密码模块中对轮询接口响应用户失效问题的处理

项目开发中，修改成功密码后，会弹框提示用户重新登陆，然后用户点击确定后，前端请求登出接口，清空本地存储，跳转登录页面。
与此同时，项目中有个轮询接口，在超时或者用户密码修改成功，原token失效的情况下，会返回302状态码，跳转登录页面。
那么如何保证修改密码成功后，不会因为轮询接口返回302重定向登录页面，导致密码修改成功后的逻辑没有来得及执行下去。
我们可以在修改密码成功后，在本地存储一个key，当有这个key存储的时候，不去请求轮询接口。然后在密码修改成功后的逻辑都顺利执行完的时候，删除这个本地存储的key。

但是这个主项目还引入了其他子项目，其他子项目也有轮询接口，如果每增加一个子项目，我们都像这个主项目的框架一样，去根据本地存储key判断是否轮询，来避免因为修改密码后用户token失效提前跳转登录页面，那么拓展性就很差。

我们的设计是：
将返回302状态码的跳转登录地址存储在contextpath字段中，而不是location字段中。
这样就使得浏览器无法实现自动重定向，因为浏览器是去取location字段进行跳转的，如果location字段缺失，那么浏览器是无法自行实现重定向的。
我们只能在前端的响应拦截器里去手动实现重定向，也就是手动从响应头中获取contextpath字段的重定向地址，调用window.location.href进行重定向。
我们将重定向的能力交予主项目框架，其他子项目没有重定向的能力。
子项目不对302做特殊处理，那么子项目即便轮询接口报错302，也不会进行重定向。
而主项目框架，对302进行手动重定向，保证了超时的时候会重新登录，又结合了本地存储的key,保证了修改密码后，不去请求轮询接口，不让轮询接口302重定向影响到修改密码成功后前端逻辑的执行。

这样一来，子项目拓展性良好，也保证了超时重新登录的处理和修改密码模块的顺利执行。