vue3+axios刷新浏览器interceptors无效问题

问题描述

vue前端应用在用户登录之后，服务端会返回一个认证token，前端会将此token存在cookie中，之后前端每次发起的向服务端的请求时，会通过axios的interceptors.request方法，来自动将cookie中的token取出来放在请求头中：

        // 请求拦截
        this.service.interceptors.request.use((config: AxiosRequestConfig<any>) => {
            config.headers = config.headers || {} // 配置请求头
            config.headers['x-access-token'] = getToken()
            return config
        }, err)

今天在调试的时候发现手动刷新浏览器页面，竟然401报错无效授权，当然如果不刷新是没问题的，刚开始怀疑是向后端发起请求时，没携带token导致，在chrome控制台调试network面板，看了下报错的连接，果然没携带token，起初怀疑是axios的interceptors拦截器没生效，在网上一通搜索，发现果然有类似的场景，然后就按照网上的代码进行改造，改造之后发现问题依然存在，于是怀疑可能排查方向不对

思考解决

在进行了思考之后，想起来我们的项目部署是前后端一体的，因为是后台管理类项目，这么部署打包最方便，不然还得拆分成两个独立的项目，一个专职后端只提供微服务接口部署在Kubernetes里面，一个专职前端只负责渲染页面部署在Nginx里面，这样比较麻烦，我们前后端一体部署的时候可以将前端页面打包后拷贝到后端spring-boot的resouces下的static目录下，这样就可以一体部署到Kubenetes里面。

前后端部署一体的时候，因为前端请求的Path路径在后端的controller里面是找不到的，所以服务端会返回404，这个时候我们配置ErrorPage到index.html页面中，就完成了前端SPA页面的初始化，服务端代码如下：

@EnableAsync
@SpringBootApplication
public class DworksApplication {
    private static Logger logger = LoggerFactory.getLogger(DworksApplication.class);

    public static void main(String[] args) {
            SpringApplication.run(DworksApplication.class, args);
    }

    @Bean // fix vue page refresh cause 404 problem
    public WebServerFactoryCustomizer<ConfigurableWebServerFactory> webServerFactoryCustomizer() {
        return factory -> {
            ErrorPage error404Page = new ErrorPage(HttpStatus.NOT_FOUND, "/index.html");
            factory.addErrorPages(error404Page);
        };
    }

}

ok，有了上面的背景知识后，我们再回到问题本身，为什么我看到的请求URL会返回401未授权呢？因为这些请求是Vue3路由URL，也就是说是前端SPA单页面跳转的路由，正常情况下我们访问一次，只要不刷新浏览器路由请求都是ok的，但是如果我们刷新了浏览器，前端会向后端服务再次发起请求，而此时的路由还是前端的找页面的URL，也就是说要先重新获取index.html页面，只有这个成功了，才会触发index.html里面的JS代码的执行，所以

浏览器刷新请求自然不会携带token了，因为JS库执行的前提是HTML页面已经渲染成功的前提下，所以对于这些前端请求页面的URL，我们后端必须配置成safe_url，即无须携带token也能放行，不然就会报错401提示token校验失败。

总结

如果是前后端分离的模式下，前端单独部署在Nginx里面，那自然不会出现文中的问题，因为前端资源的获取和后端token检查没关系，不过如果前端页面中axios请求，要访问后端服务接口时，还是必须要携带token的，否则就会当成不安全连接直接返回401。

如果是为了省事，前后端部署在一起，那么服务端就得注意区分收到的请求，是访问服务端的，还是前端UI的，如果是前端UI的，就直接放行就好了，不需要校验token，这样整个请求链路才是符合逻辑的，不然就会遇到文中描述的问题。