当前位置:   article > 正文

向请求头添加自定义属性,实现token功能时,出现CORS跨域导致请求失败( has been blocked by CORS policy: ... No ‘Access-Control-All)_接口在浏览器的时候 请求正常 前端发请求就报错 cors

接口在浏览器的时候 请求正常 前端发请求就报错 cors

场景:在使用 SpringBoot + Vue 进行前后端分离的开发过程中,部分功能是需要当用户登陆成功时后端(SpringBoot)向前端(Vue)返回一个token值,前端将这个token值放在以后每个请求的请求头中,后端先从拦截器中验证token值的存在,再放行请求,以确保不会被别人恶意修改、删除数据,结果出现了CORS跨域导致请求失败的情况。

上述场景出现的浏览器报错:

Access to XMLHttpRequest at ‘http://xxxxxxxx’ from origin ‘http://xxxxxxxx’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

一、排错过程:

1、猜测一:既然是CORS报错,首先就是检查跨域配置是否有问题

  以下是对后端进行的跨域配置:

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    /**
     * 解决因前后端的端口不一致导致的跨域问题
     */
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("GET","POST","PUT","OPTIONS","DELETE","PATCH")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

  经过接口访问测试后,发现问题是出在后端拦截器获取请求头中自定义属性 Authorization 的 token 值时,出现了 null 值,结果被程序判断后进行了拦截,导致了前端没有接受到响应,从而出现的错误,以下为拦截器代码:

/**
 * 访问controller之前先进行token验证
 */
@Component
public class TokenInterceptor implements HandlerInterceptor {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");// 获取请求头中携带的token值
        // token验证
        if(token!=null) {
            // 登陆时会将token值保存在redis中,在这里向redis中验证token值是否是真实存在的
            String value = stringRedisTemplate.opsForValue().get(token);
            if (value != null) {
                return true;
            }
        }
        // 验证失败,拦截请求
        return false;

    }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
2、猜测二:这时就判断前端是否没有将自定义的属性 Authorization 放在请求头中

  前端将自定义属性 Authorization 放入请求头的代码如下:

// 发送请求之前先为请求头添加Authorization字段且值为token,以应对后端接口的验证
axios.interceptors.request.use(config => {
    // 将登陆时存储在浏览器sessionStorage中的token值放入请求头中
    config.headers.Authorization = window.sessionStorage.getItem("token");
    return config;
})
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

  再检查请求头的信息:
在这里插入图片描述
  发现自定义属性 Authorization 确实已经加入了请求头中,只是后端拦截器中没有接收到该属性,但经过测试后端代码(即上述拦截器的代码)没有问题。

最后经过查阅资料,发现问题最终出在了浏览器的预检请求中…
以下解释浏览器的两种请求以及上述问题的解决方案。

二、浏览器的两种请求

  浏览器将CORS请求分成两类:简单请求(simple request)和非简单请求(not-so-simple request)。

1、简单请求

  只要同时满足以下两大条件,就属于简单请求。

(1) 请求方法是以下三种方法之一:HEAD、GET、POST
(2)HTTP的头信息不超出以下几种字段:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type:只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain

  凡是不同时满足上面两个条件,就属于非简单请求。

  由于我向请求头中添加了自定义的属性,所以发送请求时就属于非简单请求。

2、预检请求

  非简单请求的CORS请求,会在正式通信之前,增加一次HTTP查询请求,称为 “预检” 请求(preflight)。

  浏览器先询问服务器,当前网页所在的域名是否在服务器的许可名单之中,以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复,浏览器才会发出正式的XMLHttpRequest请求,否则就报错。

三、最终原因

  由于在后端拦截器中拦截了所有的请求,只有检查到请求头中真实存在的token值才会放行请求,这就导致了浏览器发起的预检请求也被拦截了(由于该请求头中没有携带自定义的 Authorization 属性,所以被拦截),最终导致正式的 XMLHttpRequest 请求没有发出去。

解决方案:由于预检请求是 OPTIONS 类型的,所以可以和后端人员沟通下在拦截器中放行 OPTIONS 类型的请求,如下:

if (request.getMethod().equals("OPTIONS")) {
    return true;
}
  • 1
  • 2
  • 3

本文仅个人纪录学习所用,如有纰漏,欢迎指正。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/很楠不爱3/article/detail/715657
推荐阅读
相关标签
  

闽ICP备14008679号