跨域，對後端工程師來說，可謂既熟悉又陌生。

這兩個月我以架構師的角色參與一款教育産品的孵化，有了一段難忘的跨域之旅。

寫這篇文章，我想分享我在跨域這個知識點的經曆和思考，希望對大家有所啟發。

1 遇見跨域

産品有多端：機構端，局方端，家長端等。每端都有獨立的域名，有的是在PC上通路，有的是通過微信公衆号來通路，有的是掃碼後H5展現。

接入層調用的接口域名統一使用

api.training.com

這個獨立的域名，通過Nginx來配置請求轉發。

通常，我們提到的跨域指：CORS。

CORS是一個

W3C

标準，全稱是"跨域資源共享"（Cross-origin resource sharing）, 它需要浏覽器和伺服器同時支援他，允許浏覽器向跨源伺服器發送

XMLHttpRequest

請求，進而克服 AJAX 隻能同源使用的限制。

那麼如何定義同源呢？我們先看下一個典型的網站的位址：

同源是指：協定、域名、端口号完全相同。

下表給出了與 URL

http://www.training.com/dir/page.html

的源進行對比的示例:

當使用者通過浏覽器通路應用（http://admin.training.com）時，調用接口的域名非同源域名(http://api.training.com)，這是顯而易見的跨域場景。

2 CORS詳解

跨域資源共享标準新增了一組 HTTP 首部字段，允許伺服器聲明哪些源站通過浏覽器有權限通路哪些資源。

規範要求，對那些可能對伺服器資料産生副作用的 HTTP 請求方法（特别是 GET 以外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），浏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），進而獲知服務端是否允許該跨域請求。

伺服器确認允許之後，才發起實際的 HTTP 請求。在預檢請求的傳回中，伺服器端也可以通知用戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關資料）。

2.1 簡單請求

當請求同時滿足如下條件時，CORS驗證機制會使用簡單請求，否則CORS驗證機制會使用預檢請求。

使用GET、POST、HEAD其中一種方法；
隻使用了如下的安全首部字段，不得人為設定其他首部字段；
- Accept
- Accept-Language
- Content-Language
- Content-Type 僅限三種之一：text/plain，multipart/form-data，application/x-www-form-urlencoded：
- HTML頭部 header field字段：DPR、Download、Save-Data、Viewport-Width、WIdth
請求中的任意 XMLHttpRequestUpload 對象均沒有注冊任何事件監聽器；XMLHttpRequestUpload 對象可以使用 XMLHttpRequest.upload 屬性通路；
請求中沒有使用 ReadableStream 對象。

簡單請求模式，浏覽器直接發送跨域請求，并在請求頭中攜帶Origin的頭，表明這是一個跨域的請求。伺服器端接到請求後，會根據自己的跨域規則，通過Access-Control-Allow-Origin和Access-Control-Allow-Methods響應頭，來傳回驗證結果。

應答中攜帶了跨域頭 Access-Control-Allow-Origin。使用 Origin 和 Access-Control-Allow-Origin 就能完成最簡單的通路控制。本例中，服務端傳回的 Access-Control-Allow-Origin: * 表明，該資源可以被任意外域通路。如果服務端僅允許來自 http://admin.training.com 的通路，該首部字段的内容如下：

Access-Control-Allow-Origin: http://admin.training.com

現在，除了 http://admin.training.com，其它外域均不能通路該資源。

2.2 預檢請求

浏覽器在發現頁面發出的請求非簡單請求，并不會立即執行對應的請求代碼，而是會觸發預先請求模式。預先請求模式會先發送preflight request（預先驗證請求），preflight request是一個OPTION請求，用于詢問要被跨域通路的伺服器，是否允許目前域名下的頁面發送跨域的請求。在得到伺服器的跨域授權後才能發送真正的HTTP請求。

OPTIONS請求頭部中會包含以下頭部：

伺服器收到OPTIONS請求後，設定頭部與浏覽器溝通來判斷是否允許這個請求。

如果preflight request驗證通過，浏覽器才會發送真正的跨域請求。

3 後端配置

後端配置我嘗試過兩種方式，經過兩個月的測試，都能非常穩定的運作。

MND推薦的Nginx配置；
SpringBoot自帶CorsFilter配置。

▍MND推薦的Nginx配置

Nginx配置相當于在請求轉發層配置。

location / {
     if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        #
        # Custom headers and headers various browsers *should* be OK with but aren't
        #
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        #
        # Tell client that this pre-flight info is valid for 20 days
        #
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
     }
     if ($request_method = 'POST') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     }
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
     }
}

在配置Access-Control-Allow-Headers屬性的時候，因為自定義的header包含簽名和token，數量較多。為了簡潔友善，我把Access-Control-Allow-Headers配置成 * 。

在Chrome和firefox下沒有任何異常，但在IE11下報了如下的錯：

Access-Control-Allow-Headers 清單中不存在請求标頭 content-type。

原來IE11要求預檢請求傳回的Access-Control-Allow-Headers的值必須以逗号分隔。

▍SpringBoot自帶CorsFilter

首先基礎架構裡預設有如下跨域配置。

public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/**")
      .allowedOrigins("*")
      .allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")
      .allowCredentials(true)
      .allowedHeaders("*")
      .maxAge(3600);
}

可是部署完成，進入還是報CORS異常：

從nginx和tomcat日志來看，僅僅收到一個OPTION請求，springboot應用裡有一個攔截器ActionInterceptor，從header中擷取token，調用使用者服務查詢使用者資訊，放入request中。當沒有擷取token資料時，會傳回給前端JSON格式資料。

但從現象來看CorsMapping并沒有生效。

為什麼呢？實際上還是執行順序的概念。下圖展示了過濾器，攔截器，控制器的執行順序。

DispatchServlet.doDispatch()

方法是SpringMVC的核心入口方法。

// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
    return;
}
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

那麼CorsMapping在哪裡初始化的呢？經過調試，定位于AbstractHandlerMapping。

protected HandlerExecutionChain getCorsHandlerExecutionChain(HttpServletRequest request,
		HandlerExecutionChain chain, CorsConfiguration config) {
		if (CorsUtils.isPreFlightRequest(request)) {
			HandlerInterceptor[] interceptors = chain.getInterceptors();
			chain = new HandlerExecutionChain(new PreFlightHandler(config), interceptors);
		}
		else {
			chain.addInterceptor(new CorsInterceptor(config));
	  }
		return chain;
	}

代碼裡有預檢判斷，通過PreFlightHandler.handleRequest()中處理，但是處于正常的業務攔截器之後。

最終選擇CorsFilter 主要基于兩點原因：

過濾器的執行順序優先級最高；
通過調試CorsFilter的源碼，發現源碼有很多細節的處理。

private CorsConfiguration corsConfig() {
    CorsConfiguration corsConfiguration = new CorsConfiguration();
    corsConfiguration.addAllowedOrigin("*");
    corsConfiguration.addAllowedHeader("*");
    corsConfiguration.addAllowedMethod("*");
    corsConfiguration.setAllowCredentials(true);
    corsConfiguration.setMaxAge(3600L);
    return corsConfiguration;
}
@Bean
public CorsFilter corsFilter() {
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", corsConfig());
    return new CorsFilter(source);
}

下面的代碼裡，allowHeader是通配符 * 的時候，CorsFilter在設定 Access-Control-Allow-Headers 的時候，會将 Access-Control-Request-Headers 以逗号拼接起來，這樣就可以避免IE11響應頭的問題。

public List<String> checkHeaders(@Nullable List<String> requestHeaders) {
   if (requestHeaders == null) {
      return null;
   }
   if (requestHeaders.isEmpty()) {
      return Collections.emptyList();
   }
   if (ObjectUtils.isEmpty(this.allowedHeaders)) {
      return null;
   }

   boolean allowAnyHeader = this.allowedHeaders.contains(ALL);
   List<String> result = new ArrayList<>(requestHeaders.size());
   for (String requestHeader : requestHeaders) {
      if (StringUtils.hasText(requestHeader)) {
         requestHeader = requestHeader.trim();
         if (allowAnyHeader) {
            result.add(requestHeader);
         }
         else {
            for (String allowedHeader : this.allowedHeaders) {
               if (requestHeader.equalsIgnoreCase(allowedHeader)) {
                  result.add(requestHeader);
                  break;
               }
            }
         }
      }
   }
   return (result.isEmpty() ? null : result);
}

浏覽器的執行效果如下:

4 preflight響應碼：200 vs 204

後端配置完成之後，團隊裡的小夥伴問我：“勇哥，那預檢請求傳回的響應碼到底是200還是204呀？”。這個問題真把我給問住了。

我司的API網關的預檢響應碼是200，CorsFilter預檢響應碼也是200。

MDN給的示例預檢響應碼全部是204。

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

我隻能采取Google大法，赫然發現大名鼎鼎的API網關Kong的開發者也針對這個問題有一番讨論。

MDN曾經推薦的preflight響應碼是200 ，是以Kong也和MDN同步成200；

The page was updated since then. See its contents on Sept 30th, 2018:

https://web.archive.org/web/20180930031917/https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
後來MDN将響應碼修改204，于是Kong的開發者争論要不要和MDN保持同步。

争論的核心點在于：有沒有迫切的必要。200響應碼運作得很好，似乎也将永遠正常運作下去。而更換成204，不确定是否有隐藏問題。
說到底，架構開發者還是依賴于浏覽器的底層實作。在這個問題上，沒有足夠權威的資料能夠支撐架構開發者，而各個知識點都散落在網絡的各個角落，充斥着不完整的細節和部分解決方案，這些都讓架構開發者非常困惑。

最後，Kong的源碼裡預檢響應碼仍然是200，并沒有和MDN保持同步。

我仔細檢視了各大主流網站，95%預檢響應碼是200。而經過兩個多月的測試，Nginx配置預檢響應碼204，在主流的浏覽器Chrome , Firefox , IE11 也沒有出現任何問題。

是以，200 works everywhere , 而204在目前主流的浏覽器裡也得到非常好的支援。

5 Chrome: 非安全私有網絡

本以為跨域問題就這樣解決了。沒想到還是有一個小插曲。

産品總監需要給客戶做示範，我負責搞定示範環境。申請域名，準備阿裡雲伺服器，應用打包，部署，一切都很順利。

可是在公司内網通路示範環境，有一個頁面一直報CORS報錯，報錯内容類似下圖：

跨域的錯誤類型是：InsecurePrivateNetwork。

這和原來遇到的跨域錯誤完全不一樣，我心裡一慌。馬上Google , 原來這是chrome更新到94之後新的特性，可以手工關閉這個特性。

打開 tab 頁面 chrome://flags/#block-insecure-private-network-requests
将其 Block insecure private network requests 設定為 Disabled , 然後重新開機就行了，這樣子就相當于把這個功能禁用掉。

但這樣是治标不治本呀。有點詭異的是，當我們不在公司内網通路示範環境的時候，示範環境完全正常，出錯的頁面也能正常通路。

仔細看官方的文檔，CORS-RFC1918 指出如下三種請求會受影響。

公共網絡通路私有網絡；
公共網絡通路本地裝置；
私有網絡通路本地裝置。

這樣，我把問題定位在這個出錯的第三方接口位址上。公司很多産品都依賴這個接口服務。當在公司内網通路的時候，該域名映射位址類似：172.16.xx.xx。

而這個ip正好是rfc1918上規定的私有網絡。

10.0.0.0     -  10.255.255.255  (10/8 prefix)
172.16.0.0   -  172.31.255.255  (172.16/12 prefix)
192.168.0.0  -  192.168.255.255 (192.168/16 prefix)

内網通過Chrome通路這個頁面的時候，會觸發非安全私有網絡攔截。

如何解決呢？官方給出的方案分兩步走：

私有網絡隻能通過Https來通路；
未來，添加特定的預檢頭，比如說：Access-Control-Request-Private-Network等。

當然還有一些臨時方法：

關閉Chrome該特性;
換用其他浏覽器比如Firefox;
關閉網絡内網開手機熱點;
修改本地host綁定外網ip。

基于官方的方案，生産環境完全使用Https，公司内網通路就沒有出現這樣的跨域問題了。

6 複盤

API網關非常适合目前産品的架構。架構設計之初，系統多端都會調用我司的API網關。API網關可以SAAS部署和私有化部署，有單獨的域名，提供完善的簽名算法。考慮到上線時間節點，團隊成員對于API網關的熟悉程度以及多套環境部署投入時間成本，為了盡快傳遞，從架構層面，我做了一些平衡和妥協。

api.training.com

這個獨立的域名，通過Nginx來配置請求轉發。同時，我和前端Leader統一了前後端協定，保持和我司API網關一緻，為後續切回API網關做前置準備。

API網關可以做鑒權，限流，灰階等，同時可以配置CORS。内部服務端不用特别關注跨域這個問題。

同時，在解決跨域的問題過程中，我的心态也發生了變化。從最初的輕視，到逐漸沉下心來，一步步了解CORS的原理，厘清楚不同解決方案的優缺點，事情也就慢慢順遂起來。我也觀察到：”有的項目組已經回報過Chrome非安全私有網絡問題，并給出了解決方案。對于技術管理者來講，一定要重視項目中回報的問題，做好梳理分析，整理預案。這樣當同類問題出現時，也會條理有序“。

7 寫到最後

2017年，我參加左耳朵耗子陳皓老師技術演講，他給我們講了一個故事。

故事的大概是：“公司軟體出現莫名BUG，使用者的費用扣了，但調用第三方接口的時候經常出現網絡問題。公司當時最厲害的人查了一周也沒有解決，而陳皓老師正在看《TCP/IP 詳解》這本書，

netstat

一看，連接配接的狀态是

CLOSE_WAIT

，意思是對方斷開了連接配接，大機率估計是對方系統的問題。于是他去了對方那邊幫他們看了一下代碼，果然是判斷條件出了問題，導緻應用直接斷開了連結。而這個問題隻花了不到兩個小時就解決了”。

當我想起陳皓老師的這個故事，回顧自己的跨域之旅，我深深的覺得細節是魔鬼，而解決問題也許就在某個不經意的細節裡。

如果我的文章對你有所幫助，還請幫忙點贊、在看、轉發一下，你的支援會激勵我輸出更高品質的文章，非常感謝！

後端工程師需要了解的跨域知識