博客

背景：在微服务架构的项目中，跨域问题一定是需要考虑的，所以在网关微服务上使用

CorsConfiguration

类来解决跨域问题，理论上这样配置完成后，应该是OK了的。

@Configuration
public class CorsConfig {
    
    @Bean
    public CorsWebFilter corsWebFilter(){
        UrlBasedCorsConfigurationSource source =
            new UrlBasedCorsConfigurationSource();
        
        CorsConfiguration corsConfiguration = new CorsConfiguration();
        //允许任何请求头
        corsConfiguration.addAllowedHeader("*");
        //允许任何方法
        corsConfiguration.addAllowedMethod("*");
        //允许任何来源
        corsConfiguration.addAllowedOrigin("*");
        //允许凭证
        corsConfiguration.setAllowCredentials(true);
        
        
        source.registerCorsConfiguration("/**",corsConfiguration);
        
        return new CorsWebFilter(source);
    }
    
    
}

在控制台发现，请求被拦截，拦截原因是跨域。这种感觉就像刚刚的网关白配置了。

再来看一下消息头，


Access-Control-Allow-Credentials

——访问控制允许凭据


Access-Control-Allow-Origin

——访问控制允许源

这两个分别都有两个

在前面的配置代码中，已经是配置过了的，但为什么会出现两份呢？

问题源头

最后的最后，发先renren-fast微服务中，也使用了该类来解决跨域问题

这样重复配置会导致冲突错误

问题解决方法

既然是冲突，肯定要去掉一方的配置就行了。从设计角度上来说，最好在网关服务上来做跨域配置，因为总不能在每一个微服务上都配置一次跨域。所以直接把 renren-fast 的跨域配置直接注释掉就行了。

新疑问出现

之前有一个老项目，架构设计几乎和这个一样，也是网关配置了跨域，renren-fast 也配置了跨域，但这个老项目，却可以正常运行。。。

最后发现，是在renren-fast又重新自定义了一个拦截器

在使用此方法配置之后再使用自定义拦截器时跨域相关配置就会失效。

原因是请求经过的先后顺序问题，当请求到来时会先进入拦截器中，而不是进入Mapping映射中，所以返回的头信息中并没有配置的跨域信息。浏览器就会报跨域异常。

找到这里，真是感叹到一物降一物，你克它，它克你，最后一起克死我、、、

总结一下

1. 微服务项目中，最后将跨域配置在网关服务上， 因为总不能在每一个微服务上都配置一次跨域
2. 如果网关已经配置了CORS跨域，其它微服务中就不要再配置了，避免重复配置导致错误。
3. 如果自定义拦截器的话，跨域相关配置会失效，原因是请求会先进入拦截器中。