Gateway 一文彻底解决跨域问题

> 原文地址：https://zhuanlan.zhihu.com/p/650705475

在 Spring Cloud 项目中，前后端分离目前很常见，在调试时，会遇到两种情况的跨域：
- 开发环境下前端直连业务服务跨域
- 浏览器请求Gateway跨域

## 业务服务跨域

前端页面通过不同域名或 IP 访问微服务的后台，例如前端人员会在本地起 HttpServer 直连后台开发本地起的服务，此时，如果不加任何配置，前端页面的请求会被浏览器跨域限制拦截，所以，业务服务常常会添加如下代码设置全局跨域：

```java
@Bean
public CorsFilter corsFilter() {
    logger.debug("CORS 限制打开");
    CorsConfiguration config = new CorsConfiguration();
    # 仅在开发环境设置为*
    config.addAllowedOrigin("*");
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    config.setAllowCredentials(true);
    UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
    configSource.registerCorsConfiguration("/**", config);
    return new CorsFilter(configSource);
}
```

## Gateway 跨域

前端页面通过不同域名或 IP 访问 SpringCloud Gateway，例如前端人员在本地起 HttpServer 直连服务器的 Gateway 进行调试。此时，同样会遇到跨域。需要在 Gateway 的配置文件中增加：

```yaml
spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
        # 仅在开发环境设置为*
          '[/**]':
            allowedOrigins: "*"
            allowedHeaders: "*"
            allowedMethods: "*"
```

## 跨域失败：'Access-Control-Allow-Origin'包含多个值问题

那么，此时直连微服务和网关的跨域问题都解决了，是不是很完美？No~ 问题来了，前端仍然会报错：“**不允许有多个’Access-Control-Allow-Origin’ CORS 头**”。

```
Access to XMLHttpRequest at 'http://192.168.2.137:8088/api/two' from origin 'http://localhost:3200' has been blocked by CORS policy:
The 'Access-Control-Allow-Origin' header contains multiple values '*, http://localhost:3200', but only one is allowed.
```

仔细查看返回的响应头，里面包含了两份 Access-Control-Allow-Origin 头。

我们用客户端版的 PostMan 做一个模拟，在请求里设置头：`Origin : *` ，查看返回结果的头:

> 不能用 Chrome 插件版，由于浏览器的限制，插件版设置 Origin 的 Header 是无效的

![](/media/202312/2023-12-08_2202510.41193129960290686.png)

发现问题了：

Vary 和 Access-Control-Allow-Origin 两个头重复了两次，其中浏览器对后者有唯一性限制！

### 分析

Spring Cloud Gateway 是基于 Spring WebFlux 的，所有 web 请求首先是交给 DispatcherHandler 进行处理的，将 HTTP 请求交给具体注册的 handler 去处理。

我们知道 Spring Cloud Gateway 进行请求转发，是在配置文件里配置路由信息，一般都是用 url predicates 模式，对应的就是 RoutePredicateHandlerMapping 。所以，DispatcherHandler 会把请求交给 RoutePredicateHandlerMapping.

![](/media/202312/2023-12-08_2202510.819175131987177.png)

那么，接下来看下 RoutePredicateHandlerMapping.getHandler(ServerWebExchange exchange) 方法，默认提供者是其父类 AbstractHandlerMapping ：

```text
@Override
public Mono<Object> getHandler(ServerWebExchange exchange) {
    return getHandlerInternal(exchange).map(handler -> {
        if (logger.isDebugEnabled()) {
            logger.debug(exchange.getLogPrefix() + "Mapped to " + handler);
        }
        ServerHttpRequest request = exchange.getRequest();
        // 可以看到是在这一行就进行 CORS 判断，两个条件：
        // 1. 是否配置了 CORS，如果不配的话，默认是返回 false 的
        // 2. 或者当前请求是 OPTIONS 请求，且头里包含 ORIGIN 和 ACCESS_CONTROL_REQUEST_METHOD
        if (hasCorsConfigurationSource(handler) || CorsUtils.isPreFlightRequest(request)) {
            CorsConfiguration config = (this.corsConfigurationSource != null ? this.corsConfigurationSource.getCorsConfiguration(exchange) : null);
            CorsConfiguration handlerConfig = getCorsConfiguration(handler, exchange);
            config = (config != null ? config.combine(handlerConfig) : handlerConfig);
            //此处交给 DefaultCorsProcessor 去处理了
            if (!this.corsProcessor.process(config, exchange) || CorsUtils.isPreFlightRequest(request)) {
                return REQUEST_HANDLED_HANDLER;
            }
        }
        return handler;
    });
}
```

> 注：网上有些关于修改 Gateway 的 CORS 设定的方式，是跟前面 SpringBoot 一样，实现一个 CorsWebFilter 的 Bean，靠写代码提供 CorsConfiguration ，而不是修改 Gateway 的配置文件。其实本质，都是将配置交给 corsProcessor 去处理，殊途同归。但靠配置解决永远比 hard code 来的优雅。

该方法把 Gateway 里定义的所有的 GlobalFilter 加载进来，作为 handler 返回，但在返回前，先进行 CORS 校验，获取配置后，交给 corsProcessor 去处理，即 DefaultCorsProcessor 类

看下 DefaultCorsProcessor 的 process 方法：

```java
@Override
public boolean process(@Nullable CorsConfiguration config, ServerWebExchange exchange) {

ServerHttpRequest request = exchange.getRequest();
    ServerHttpResponse response = exchange.getResponse();
    HttpHeaders responseHeaders = response.getHeaders();

List<String> varyHeaders = responseHeaders.get(HttpHeaders.VARY);
    if (varyHeaders == null) {
        // 第一次进来时，肯定是空，所以加了一次 VERY 的头，包含 ORIGIN, ACCESS_CONTROL_REQUEST_METHOD 和 ACCESS_CONTROL_REQUEST_HEADERS
        responseHeaders.addAll(HttpHeaders.VARY, VARY_HEADERS);
    }
    else {
        for (String header : VARY_HEADERS) {
            if (!varyHeaders.contains(header)) {
                responseHeaders.add(HttpHeaders.VARY, header);
            }
        }
    }

if (!CorsUtils.isCorsRequest(request)) {
        return true;
    }

if (responseHeaders.getFirst(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN) != null) {
        logger.trace("Skip: response already contains \"Access-Control-Allow-Origin\"");
        return true;
    }

boolean preFlightRequest = CorsUtils.isPreFlightRequest(request);
    if (config == null) {
        if (preFlightRequest) {
            rejectRequest(response);
            return false;
        }
        else {
            return true;
        }
    }

return handleInternal(exchange, config, preFlightRequest);
}

// 在这个类里进行实际的 CORS 校验和处理
protected boolean handleInternal(ServerWebExchange exchange,
                                 CorsConfiguration config, boolean preFlightRequest) {

ServerHttpRequest request = exchange.getRequest();
    ServerHttpResponse response = exchange.getResponse();
    HttpHeaders responseHeaders = response.getHeaders();

String requestOrigin = request.getHeaders().getOrigin();
    String allowOrigin = checkOrigin(config, requestOrigin);
    if (allowOrigin == null) {
        logger.debug("Reject: '" + requestOrigin + "' origin is not allowed");
        rejectRequest(response);
        return false;
    }

HttpMethod requestMethod = getMethodToUse(request, preFlightRequest);
    List<HttpMethod> allowMethods = checkMethods(config, requestMethod);
    if (allowMethods == null) {
        logger.debug("Reject: HTTP '" + requestMethod + "' is not allowed");
        rejectRequest(response);
        return false;
    }

List<String> requestHeaders = getHeadersToUse(request, preFlightRequest);
    List<String> allowHeaders = checkHeaders(config, requestHeaders);
    if (preFlightRequest && allowHeaders == null) {
        logger.debug("Reject: headers '" + requestHeaders + "' are not allowed");
        rejectRequest(response);
        return false;
    }
    //此处添加了 AccessControllAllowOrigin 的头
    responseHeaders.setAccessControlAllowOrigin(allowOrigin);

if (preFlightRequest) {
        responseHeaders.setAccessControlAllowMethods(allowMethods);
    }

if (preFlightRequest && !allowHeaders.isEmpty()) {
        responseHeaders.setAccessControlAllowHeaders(allowHeaders);
    }

if (!CollectionUtils.isEmpty(config.getExposedHeaders())) {
        responseHeaders.setAccessControlExposeHeaders(config.getExposedHeaders());
    }

if (Boolean.TRUE.equals(config.getAllowCredentials())) {
        responseHeaders.setAccessControlAllowCredentials(true);
    }

if (preFlightRequest && config.getMaxAge() != null) {
        responseHeaders.setAccessControlMaxAge(config.getMaxAge());
    }

return true;
}
```

可以看到，在 DefaultCorsProcessor 中，根据我们在 appliation.yml 中的配置，给 Response 添加了 Vary 和 Access-Control-Allow-Origin 的头。

![](/media/202312/2023-12-08_220827_3895920.11855677827864419.png)

再接下来就是进入各个 GlobalFilter 进行处理了，其中 NettyRoutingFilter 是负责实际将请求转发给后台微服务，并获取 Response 的，重点看下代码中 filter 的处理结果的部分：

![](/media/202312/2023-12-08_220839_4614600.35001678313429085.png)

其中以下几种 header 会被过滤掉的：

![](/media/202312/2023-12-08_220852_2709930.4317491670616551.png)

很明显，在图里的第 3 步中，如果后台服务返回的 header 里有 Vary 和 Access-Control-Allow-Origin ，这时由于是 putAll，没有做任何去重就加进去了，必然会重复，看看 DEBUG 结果验证一下：

![](/media/202312/2023-12-08_220904_9320430.5699332536105911.png)

验证了前面的发现。

### 解决

解决的方案有两种：

#### 1. 利用 DedupeResponseHeader 配置

```yaml
spring:
    cloud:
        gateway:
          globalcors:
            cors-configurations:
              '[/**]':
                allowedOrigins: "*"
                allowedHeaders: "*"
                allowedMethods: "*"
          default-filters:
          - DedupeResponseHeader=Vary Access-Control-Allow-Origin Access-Control-Allow-Credentials, RETAIN_FIRST
```

DedupeResponseHeader 加上以后会启用 DedupeResponseHeaderGatewayFilterFactory ，在其中，dedupe 方法可以按照给定策略处理。

```java
private void dedupe(HttpHeaders headers, String name, Strategy strategy) {
  List<String> values = headers.get(name);
  if (values == null || values.size() <= 1) {
   return;
  }
  switch (strategy) {
  // 只保留第一个
  case RETAIN_FIRST:
   headers.set(name, values.get(0));
   break;
  // 保留最后一个
  case RETAIN_LAST:
   headers.set(name, values.get(values.size() - 1));
   break;
  // 去除值相同的
  case RETAIN_UNIQUE:
   headers.put(name, values.stream().distinct().collect(Collectors.toList()));
   break;
  default:
   break;
  }
 }
```

- 如果请求中设置的 Origin 的值与我们自己设置的是同一个，例如生产环境设置的都是自己的域名`http://xxx.com`或者开发测试环境设置的都是`*`（浏览器中是无法设置 Origin 的值，设置了也不起作用，浏览器默认是当前访问地址），那么可以选用 RETAIN_UNIQUE 策略，去重后返回到前端。
- 如果请求中设置的 Oringin 的值与我们自己设置的不是同一个，RETAIN_UNIQUE 策略就无法生效，比如 `*` 和 `xxx.com`是两个不一样的 Origin，最终还是会返回两个 Access-Control-Allow-Origin 的头。此时，看代码里，response 的 header 里，先加入的是我们自己配置的 Access-Control-Allow-Origin 的值，所以，我们可以将策略设置为 RETAIN_FIRST，只保留我们自己设置的。

大多数情况下，我们想要返回的是我们自己设置的规则，所以直接使用 RETAIN_FIRST 即可。实际上，DedupeResponseHeader 可以针对所有头，做重复的处理。

#### 2. 手动写一个 CorsResponseHeaderFilter 的 GlobalFilter 去修改 Response 中的头

```java
@Component
public class CorsResponseHeaderFilter implements GlobalFilter, Ordered {

private static final Logger logger = LoggerFactory.getLogger(CorsResponseHeaderFilter.class);

private static final String ANY = "*";

@Override
    public int getOrder() {
        // 指定此过滤器位于NettyWriteResponseFilter之后
        // 即待处理完响应体后接着处理响应头
        return NettyWriteResponseFilter.WRITE_RESPONSE_FILTER_ORDER + 1;
    }

@Override
    @SuppressWarnings("serial")
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            exchange.getResponse().getHeaders().entrySet().stream()
                    .filter(kv -> (kv.getValue() != null && kv.getValue().size() > 1))
                    .filter(kv -> (kv.getKey().equals(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN)
                            || kv.getKey().equals(HttpHeaders.ACCESS_CONTROL_ALLOW_CREDENTIALS)
                            || kv.getKey().equals(HttpHeaders.VARY)))
                    .forEach(kv ->
                    {
                        // Vary只需要去重即可
                        if(kv.getKey().equals(HttpHeaders.VARY))
                            kv.setValue(kv.getValue().stream().distinct().collect(Collectors.toList()));
                        else{
                            List<String> value = new ArrayList<>();
                            if(kv.getValue().contains(ANY)){  //如果包含*，则取*
                                value.add(ANY);
                                kv.setValue(value);
                            }else{
                                value.add(kv.getValue().get(0)); // 否则默认取第一个
                                kv.setValue(value);
                            }
                        }
                    });
        }));
    }
}
```

此处有两个地方要注意：

1）根据下图可以看到，在取得返回值后，Filter 的 Order 值越大，越先处理 Response，而真正将 Response 返回到前端的，是 NettyWriteResponseFilter, 我们要想在它之前修改 Response，则 Order 的值必须比 NettyWriteResponseFilter.WRITE_RESPONSE_FILTER_ORDER 大。

![](/media/202312/2023-12-08_2209350.566093427005545.png)

2）修改后置 filter 时，网上有些文字使用的是 Mono.defer 去做的，这种做法，会从此 filter 开始，重新执行一遍它后面的其他 filter，一般我们会添加一些认证或鉴权的 GlobalFilter ，就需要在这些 filter 里用 ServerWebExchangeUtils.isAlreadyRouted(exchange) 方法去判断是否重复执行，否则可能会执行二次重复操作，所以建议使用 fromRunnable 避免这种情况。