CORS 專題

時間  2019-11-30
標籤 cors 專題 简体版
原文   原文鏈接

CORS（跨域資源共享，Cross-Origin Resource Sharing）
CORS其實出現時間不短了，它在維基百科上的定義是：跨域資源共享（CORS ）是一種網絡瀏覽器的技術規範，它爲Web服務器定義了一種方式，容許網頁從不一樣的域訪問其資源。而這種訪問是被同源策略所禁止的。
CORS系統定義了一種瀏覽器和服務器交互的方式來肯定是否容許跨域請求。 它是一個妥協，有更大的靈活性，但比起簡單地容許全部這些的要求來講更加安全。

javascript

好比，
站點 http://domain-a.com 的某 HTML 頁面經過 <img> 的 src 請求 http://domain-b.com/image.jpg。
網絡上的許多頁面都會加載來自不一樣域的CSS樣式表，圖像和腳本等資源。

出於安全考慮，瀏覽器會限制從腳本內發起的跨域HTTP請求。
例如，XMLHttpRequest 和 Fetch 遵循同源策略。
所以，使用 XMLHttpRequest或 Fetch 的Web應用程序只能將HTTP請求發送到其本身的域。
爲了改進Web應用程序，開發人員要求瀏覽器廠商容許跨域請求。html

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS前端


同源策略， 即JavaScript只能訪問同域下的內容

Same-origin policy
From Wikipedia, the free encyclopediahtml5

In computing, the same-origin policy is an important concept in the web application security model.
Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.
An origin is defined as a combination of URI scheme, hostname, and port number.
This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model.java

https://en.wikipedia.org/wiki/Same-origin_policy


jquery

而W3C的官方文檔目前仍是工做草案，可是正在朝着W3C推薦的方向前進。git

簡言之，CORS就是爲了讓AJAX能夠實現可控的跨域訪問而生的。程序員

 

 

 

 

瀏覽器的同源策略，便是瀏覽器之間要隔離不一樣域的內容，禁止互相操做。github

好比，當你打開了多個網站，若是容許多個網站之間互相操做，那麼其中一個木馬網站就能夠經過這種互相操做進行一系列的非法行爲，獲取你在各個網站的相關信息，很明顯這是不安全的，因此同源策略避免了不少這樣的問題。web

可是同時也帶來了一些問題，好比有時候你想經過本身的網站去獲取另外一個本身的網站的一些資料信息，可是因爲二者域名不一樣，因此就被同源策略隔離了，那麼這個時候就須要瞭解一下瀏覽器的跨域問題。

 

跨域常見的兩種方式，分別是jsonp和新推出的cors，即cross-origin resourse sharing，其實這貨出現的時間也不短了，只是我如今才注意到而已。

先說說jsonp，先說個簡單的例子再講百度的例子。

咱們有個www.a.com的頁面

<script type="text/javascript"
src="http://www.b.com?name=qiangzi"></script>
<script type="text/javascript">
function jsonp(json){
    alert(json[‘age’]);
}
</script>

 

這是請求 http://www.b.com?name=qiangzi 返回的js文件。

jsonp({'name':'qiangzi','age':20});

事先聲明，我的沒有實際的使用過jsonp去進行跨域操做，因此全部的分析都是猜測，如有不對請指出。

咱們來試着去分析上面的代碼，a頁面事先寫好了一個回調函數，便是供咱們請求回的js回調的函數，這裏的回調函數式alert參數組中的年齡。

咱們再看咱們的請求，首先咱們的請求是寫在script標籤裏面的，因此說明正常來講咱們請求回來的內容應該是一段js文件。接着看，咱們發現請求的時候同時傳了一個參數過去name="qiangzi"，因此咱們基本能夠猜想在www.b.com服務器那邊，接收到a頁面的請求，同時接收到傳過來的name數據，根據這個數據進行相應的查詢，找到了{name:"qiangzi",age:20}這樣的一段數據以後，咱們的b服務器因而就構造了一段這樣的js文件傳給請求的頁面

jsonp({'name':'qiangzi','age':20});

也就是在原頁面輸出咱們請求的name對應的年齡。很明顯，咱們請求的script標籤中的src不能寫死，而應該是一個動態的插入name值的過程。

從前臺寫好回調函數，到根據請求的參數值構造請求連接，跨域服務器根據連接進行相應處理返回數據並執行回調函數，這整一個過程就是jsonp的過程，固然上述只是我我的猜測，畢竟沒有去實現過，因此有錯望大神們指出。

那麼咱們按照這個思路再來看看百度搜索下拉框的jsonp跨域操做。

咱們在百度搜索框輸入jsonp，立刻出現了下拉框，分別有jsonp json jsonp跨域等等，其實這一過程就是使用到了jsonp跨域處理，具體怎麼過跨法，咱們打開F12，找到network這裏能夠看到這樣的一個請求

也就是這個連接

https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=jsonp&json=1&p=3&sid=19637_18286_1442_17711_18240_17944_19568_19806_19558_19808_19843_19861_17001_15825_12254&req=2&bs=xmlhttprequest&pbs=jsonp&csor=5&pwd=json&cb=jQuery1102032008872299992563_1463242088002&_=1463242088035

點擊咱們能夠看到這樣的一段東西

那麼這樣的一段東西實際上是什麼呢？其實這就是咱們jsonp跨域請求回來的數據以及調用的函數。

接下來就按照咱們剛纔的思路分析下整個過程。

首先，百度在前臺寫好了一個回調函數，便是接收跨域返回來的數據而且出現下拉框，把數據填充到下拉框中。當咱們在百度搜索的輸入框（注意區分開此處的輸入框和上句話中的下拉框）輸入咱們要搜索的內容時，此時百度頁面立刻獲取咱們輸入的值，並構造請求，即咱們上文中提到的

https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=jsonp&json=1&p=3&sid=19637_18286_1442_17711_18240_17944_19568_19806_19558_19808_19843_19861_17001_15825_12254&req=2&bs=xmlhttprequest&pbs=jsonp&csor=5&pwd=json&cb=jQuery1102032008872299992563_1463242088002&_=1463242088035

對於這一段請求，我我的看着都以爲有點怕怕的，因此爲了方便理解jsonp咱們簡化下應該能夠這樣理解

https://sp0.baidu.com/su?wd=jsonp

服務器查詢jsonp對應的聯想關鍵詞，並把這些關鍵詞填充在一個數組中，而後把這個數組做爲參數調用前臺寫好的回調函數，返回這段js文件給前臺，而後咱們就看到了在搜索框輸入jsonp而後下拉框出現一系列關鍵詞的功能。

至此，關於jsonp的例子講訴差很少結束。那麼jsonp有哪些優缺點呢？

jsonp的優勢是兼容全部的瀏覽器，不管是主流的仍是之前的。而它的缺點則是因爲jsonp發起的請求是get方式的，即參數是填充在請求地址上，因此這種方式發送的數據有限制。

關於jsonp再補充點內容，其實不知道你們有沒有想過，咱們使用的不少API接口，調用他們返回的數據，其實這一過程就是跨域了，由於咱們請求的是別的站點的數據，不作跨域處理咱們是不可能得到信息的，只是有時候咱們是按着API說明文檔照寫的因此忽視了這個

我這裏有個國外的API，根據填寫的郵編搜索郵編所對應的位置信息

http://www.geonames.org/postalCodeLookupJSON?postalcode=10504&country=US&callback=?

在這個API中咱們須要填寫三個參數，一個是郵編號碼，另外一個是對應的國家，而第三個就是咱們的回調函數。

這個是該API接口返回的數據

整個API調用的過程就是，咱們在前臺寫好一個callback函數，這個callback函數的功能就是根據咱們的需求而寫，而後在構造請求的時候把這個callback函數的名稱寫在請求對應的callback上。至於其餘的郵編號碼國家這些固然也是在咱們前臺頁面構造的。構造完這些請求以後，當咱們發起請求的時候，API服務器端就會根據咱們的請求信息，拿到相應的數據，並把這些數據放到咱們寫的回調函數對應的參數中傳回來，並進行調用，整個API調用完畢。

 

說完了jsonp，接下來講說cors跨域這玩意。

在前文看到同源策略的時候，不知道你們有沒有想過，難道就不能讓兩個跨域的站點寫一個祕密的協議，達成一種交易從而使得二者能夠進行跨域操做獲取數據之類的嗎？嗯，我我的以爲cors作的就是這件事。

關於cors在維基百科上的定義是這樣的：跨域資源共享（CORS ）是一種網絡瀏覽器的技術規範，它爲Web服務器定義了一種方式，容許網頁從不一樣的域訪問其資源。而這種訪問是被同源策略所禁止的。CORS系統定義了一種瀏覽器和服務器交互的方式來肯定是否容許跨域請求。它是一個妥協，有更大的靈活性，但比起簡單地容許全部這些的要求來講更加安全。

要想實現cors跨域，須要作的就是兩件事，一個是咱們的瀏覽器要支持cors跨域這一操做（主流谷歌和火狐均支持，ie版本要高於ie10才行），另外，咱們的服務器端必需要設置好Access-Control-Allow-Origin從而支持跨域操做。

cors相對於jsonp而言的好處就是支持全部的請求方式，不止是get請求，還支持post,put請求等等，而它的缺點就很明顯，沒法兼容全部的瀏覽器，對於要兼容到老式瀏覽器而言，仍是使用jsonp好點。

 http://www.cnblogs.com/jelly7723/p/5494330.html

 

序言：跨域資源共享向來都是熱門的需求，使用CORS能夠幫助咱們快速實現跨域訪問，只需在服務端進行受權便可，無需在前端添加額外設置，比傳統的JSONP跨域更安全和便捷。

1、基本介紹

簡單來講，CORS是一種訪問機制，英文全稱是Cross-Origin Resource Sharing，即咱們常說的跨域資源共享，經過在服務器端設置響應頭，把發起跨域的原始域名添加到Access-Control-Allow-Origin 便可。

1. CORS工做原理

CORS實現跨域訪問並非一蹴而就的，須要藉助瀏覽器的支持，從原理題圖咱們能夠清楚看到，簡單的請求（一般指GET/POST/HEAD方式，並無去增長額外的請求頭信息）直接建立了跨域請求的XHR對象，而複雜的請求則要求先發送一個」預檢」請求，待服務器批准後才能真正發起跨域訪問請求。

根據官方文檔W3C規範-CORS 的描述，目前CORS使用了以下頭部信息：

注：請求頭信息由瀏覽器檢測到跨域自動添加，無需過多幹預，重點放在Response headers，它能夠幫助咱們在服務器進行跨域受權，例如容許哪些原始域可放行，是否須要攜帶Cookie信息等。

2. Request Headers（請求頭）

  • Origin

    表示跨域請求的原始域。

  • Access-Control-Request-Method

    表示跨域請求的方式。（如GET/POST）

  • Access-Control-Request-Headers

    表示跨域請求的請求頭信息。

3. Response headers（響應頭 ）

  • Access-Control-Allow-Origin

    表示容許哪些原始域進行跨域訪問。（字符數組）

  • Access-Control-Allow-Credentials

    表示是否容許客戶端獲取用戶憑據。（布爾類型）
    使用場景：例如如今從瀏覽器發起跨域請求，而且要附帶Cookie信息給服務器。則必須具有兩個條件：1. 瀏覽器端：發送AJAX請求前需設置通訊對象XHR的withCredentials 屬性爲true。 2.服務器端：設置Access-Control-Allow-Credentials爲true。兩個條件缺一不可，不然即便服務器贊成發送Cookie，瀏覽器也沒法獲取。正確姿式以下：

  • Access-Control-Allow-Methods

    表示跨域請求的方式的容許範圍。（例如只受權GET/POST）

  • Access-Control-Allow-Headers

    表示跨域請求的頭部的容許範圍。

  • Access-Control-Expose-Headers

    表示暴露哪些頭部信息，並提供給客戶端。（由於基於安全考慮，若是沒有設置額外的暴露，跨域的通訊對象XMLHttpRequest只能獲取標準的頭部信息）

  • Access-Control-Max-Age

    表示預檢請求 [Preflight Request] 的最大緩存時間。

2、CORS實現跨域訪問

受權方式

  • 方式1：返回新的CorsFilter
  • 方式2：重寫WebMvcConfigurer
  • 方式3：使用註解（@CrossOrigin）
  • 方式4：手工設置響應頭（HttpServletResponse ）

注：CorsFilter / WebMvcConfigurer / @CrossOrigin 須要SpringMVC 4.2 以上的版本才支持，對應SpringBoot 1.3 版本以上都支持這些CORS特性。不過，使用SpringMVC4.2 如下版本的小夥伴也不用慌，直接使用方式4經過手工添加響應頭來受權CORS跨域訪問也是能夠的。附：在SpringBoot 1.2.8 + SpringMVC 4.1.9 親測成功。

注：方式1和方式2屬於全局CORS配置，方式3和方式4屬於局部CORS配置。若是使用了局部跨域是會覆蓋全局跨域的規則，因此能夠經過@CrossOrigin註解來進行細粒度更高的跨域資源控制。

1. 返回新的CorsFilter（全局跨域）

在任意配置類，返回一個新的CorsFilter Bean，並添加映射路徑和具體的CORS配置信息。

package com.hehe.yyweb.config;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        //1.添加CORS配置信息
        CorsConfiguration config = new CorsConfiguration();
          //放行哪些原始域
          config.addAllowedOrigin("*");
          //是否發送Cookie信息
          config.setAllowCredentials(true);
          //放行哪些原始域(請求方式)
          config.addAllowedMethod("*");
          //放行哪些原始域(頭部信息)
          config.addAllowedHeader("*");
          //暴露哪些頭部信息（由於跨域訪問默認不能獲取所有頭部信息）
          config.addExposedHeader("*");

        //2.添加映射路徑
        UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
        configSource.registerCorsConfiguration("/**", config);

        //3.返回新的CorsFilter.
        return new CorsFilter(configSource);
    }
}

2. 重寫WebMvcConfigurer（全局跨域）

在任意配置類，返回一個新的WebMvcConfigurer Bean，並重寫其提供的跨域請求處理的接口，目的是添加映射路徑和具體的CORS配置信息。

package com.hehe.yyweb.config;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            //重寫父類提供的跨域請求處理的接口
            public void addCorsMappings(CorsRegistry registry) {
                //添加映射路徑
                registry.addMapping("/**")
                        //放行哪些原始域
                        .allowedOrigins("*")
                        //是否發送Cookie信息
                        .allowCredentials(true)
                        //放行哪些原始域(請求方式)
                        .allowedMethods("GET","POST", "PUT", "DELETE")
                        //放行哪些原始域(頭部信息)
                        .allowedHeaders("*")
                        //暴露哪些頭部信息（由於跨域訪問默認不能獲取所有頭部信息）
                        .exposedHeaders("Header1", "Header2");
            }
        };
    }
}

3. 使用註解（局部跨域）

在方法上（@RequestMapping）使用註解 @CrossOrigin ：

@RequestMapping("/hello")
    @ResponseBody
    @CrossOrigin("http://localhost:8080") 
    public String index( ){
        return "Hello World";
    }

或者在控制器（@Controller）上使用註解 @CrossOrigin ：

@Controller
@CrossOrigin(origins = "http://xx-domain.com", maxAge = 3600)
public class AccountController {

    @RequestMapping("/hello")
    @ResponseBody
    public String index( ){
        return "Hello World";
    }
}

4. 手工設置響應頭（局部跨域 ）

使用HttpServletResponse對象添加響應頭（Access-Control-Allow-Origin）來受權原始域，這裏Origin的值也能夠設置爲」*」 ，表示所有放行。

@RequestMapping("/hello")
    @ResponseBody
    public String index(HttpServletResponse response){
        response.addHeader("Access-Control-Allow-Origin", "http://localhost:8080");
        return "Hello World";
    }

3、測試跨域訪問

首先使用 Spring Initializr 快速構建一個Maven工程，什麼都不用改，在static目錄下，添加一個頁面：index.html 來模擬跨域訪問。目標地址: http://localhost:8090/hello

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8"/>
    <title>Page Index</title>
</head>
<body>
<h2>前臺系統</h2>
<p id="info"></p>
</body>
<script src="webjars/jquery/3.2.1/jquery.js"></script>
<script>
    $.ajax({
        url: 'http://localhost:8090/hello',
        type: "POST",
        success: function (data) {
            $("#info").html("跨域訪問成功:"+data);
        },
        error: function (data) {
            $("#info").html("跨域失敗!!");
        }
    })
</script>
</html>

 

而後建立另外一個工程，在Root Package添加Config目錄並建立配置類來開啓全局CORS。

@Configuration
public class GlobalCorsConfig {

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**");
            }
        };
    }
}
 

接着，簡單編寫一個Rest接口 ，並指定應用端口爲8090。
 

 
 
@SpringBootApplication
@RestController
public class YyWebApplication {

    @Bean
    public TomcatServletWebServerFactory tomcat() {
        TomcatServletWebServerFactory tomcatFactory = new TomcatServletWebServerFactory();
        tomcatFactory.setPort(8090); //默認啓動8090端口
        return tomcatFactory;
    }

    @RequestMapping("/hello")
    public String index() {
        return "Hello World";
    }

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

 

 
 

最後分別啓動兩個應用，而後在瀏覽器訪問：http://localhost:8080/index.html ，能夠正常接收JSON數據，說明跨域訪問成功！！
 

嘗試把全局CORS關閉，或者沒有單獨在方法或類上受權跨域，再次訪問：http://localhost:8080/index.html 時會看到跨域請求失敗！！
 

 

4、源碼和文檔
 

Github源碼：SpringBoot-Cross-Orgin
 

專題地址：SpringBoot 從入門到上癮
 

規範文檔：W3C規範-CORS
 

傳統文檔：SpringMVC-CORS 使用手冊
 

推薦閱讀：跨域資源共享 CORS 詳解 - 阮一峯
 

http://www.spring4all.com/article/177
 

 
 

 
 

概述
 

 
 
     
  
  • CORS能作什麼：
    •  
 
 

 


       正常使用AJAX會須要正常考慮跨域問題，因此偉大的程序員們又折騰出了一系列跨域問題的解決方案，如JSONP、flash、ifame、xhr2等等。 

 


       本文介紹的CORS就是一套AJAX跨域問題的解決方案。 

 


    

 

 
 
     
  
  •  CORS的原理：
    •  
 
 

 


       CORS定義一種跨域訪問的機制，可讓AJAX實現跨域訪問。CORS 容許一個域上的網絡應用向另外一個域提交跨域 AJAX 請求。實現此功能很是簡單，只需由服務器發送一個響應標頭便可。 

 


    

 

 
 
     
  
  • CORS瀏覽器支持狀況以下圖：
    •  
 
 

 


          
  

 


        
  

 


  　　喜聞樂見、普大喜奔的支持狀況，尤爲是在 
 移動終端上，除了opera Mini； 

 


  　　PC上的現代瀏覽器都能友好的支持，除了IE9-，不過前端工程師對這種狀況早應該習慣了... 

 


        
  

 


    

 

CORS啓航
 


    

 


  　　假設咱們頁面或者應用已在 http://www.test1.com 上了，而咱們打算從 http://www.test2.com 請求提取數據。通常狀況下，若是咱們直接使用 AJAX 來請求將會失敗，瀏覽器也會返回「源不匹配」的錯誤，" 
 跨域"也就以此由來。 

 


  　　利用 CORS，http://www.test2.com 只需添加一個標頭，就能夠容許來自 http://www.test1.com 的請求，下圖是我在PHP中的 hander() 設置， 
 「*」號表示容許任何域向咱們的服務端提交請求： 

 


        
  

 

　　也能夠設置指定的域名，如域名 http://www.test2.com ，那麼就容許來自這個域名的請求：
 


        
  

 


        

 


  　　當前我設置的header爲「*」，任意一個請求過來以後服務端咱們均可以進行處理&響應，那麼在調試工具中能夠看到其頭信息設置，其中見紅框中有一項信息是「 
 Access-Control-Allow-Origin：* 」，表示咱們已經啓用CORS，以下圖。 

 


  　　PS：因爲demo都在我廠的兩臺測試機間完成，外網也不能訪問，因此在這就不提供demo了，見諒 
  
 

         
   
 
 
 

    　　簡單的一個header設置，一個支持跨域&POST請求的server就完成了:) 
 
 
 

     
 
 
 

   　　固然，若是沒有開啓CORS一定失敗的啦，以下圖： 
 
 
 

   　　 
   
 
 
 
問題&小結
 
 
     
  
  • 剛剛說到的兼容性。CORS是W3C中一項較新的方案，因此部分瀏覽器尚未對其進行支持或者完美支持，詳情可移至 http://www.w3.org/TR/cors/
    •  
  
  • 安全問題。CORS提供了一種跨域請求方案，但沒有爲安全訪問提供足夠的保障機制，若是你須要信息的絕對安全，不要依賴CORS當中的權限制度，應當使用更多其它的措施來保障，好比OAuth2。
    •  
 
 
 
 
  
 
   

       
   
 
   

     　　自認爲的cors使用場景： 
   
 
   
 
    
     
     
  • cors在移動終端支持的不錯，能夠考慮在移動端全面嘗試；PC上有不兼容和沒有完美支持，因此當心踩坑。固然瀏覽器兼容就是個僞命題，說不許某個瀏覽器的某個版本就完美兼容了，說不許就有點小坑，尼瑪傷不起！～
    •  
     
  • jsonp是get形式，承載的信息量有限，因此信息量較大時CORS是不二選擇；
    •  
     
  • 配合新的JSAPI(fileapi、xhr2等)一塊兒使用，實現強大的新體驗功能。
    •  
    
 
   
 
  
 
 
 

 

http://www.cnblogs.com/Darren_code/p/cors.html
 

 
 

一，簡單跨域（不帶頭 不帶參數）
 要在servlet的doget或者dopost裏增長返回頭
 resp.addHeader("Access-Control-Allow-Origin",
"http://zhucetest.duapp.com"); 若是是公共的則返回*便可。
二，複雜跨域
 瀏覽器會先發起一個驗證的網絡鏈接到servlet的 doOptions 在doOptions裏返回
resp.addHeader("Access-Control-Allow-Origin",
"http://zhucetest.duapp.com");
resp.addHeader("Access-Control-Allow-Methods","GET,POST,OPTIONS"); 
resp.addHeader("Access-Control-Allow-Headers", "Content-type,hello");
 
resp.addHeader("Access-Control-Max-Age", "50");便可
三，post傳參 加這句話
 xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
四，get傳參 直接加在url裏
五，servelet接受參數 
 直接調用req.getparams...
 

http://yunshangbuhe.iteye.com/blog/1979587
 

 
 

 
 

 

本文概述了跨域資源共享機制及其所涉及的 HTTP 首部字段。
 

概述EDIT
 

跨域資源共享標準新增了一組 HTTP 首部字段，容許服務器聲明哪些源站有權限訪問哪些資源。另外，規範要求，對那些可能對服務器數據產生反作用的 HTTP 請求方法（特別是 GET 之外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否容許該跨域請求。服務器確認容許以後，才發起實際的 HTTP 請求。在預檢請求的返回中，服務器端也能夠通知客戶端，是否須要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關數據）。
 

接下來的內容將討論相關場景，並剖析該機制所涉及的 HTTP 首部字段。
 

若干訪問控制場景EDIT
 

這裏，咱們使用三個場景來解釋跨域資源共享機制的工做原理。這些例子都使用 XMLHttpRequest 對象。
 

本文中的 JavaScript 代碼片斷均可以從 http://arunranga.com/examples/access-control/ 得到。另外，使用支持跨域  XMLHttpRequest 的瀏覽器訪問該地址，能夠看到代碼的實際運行結果。
 

關於服務端對跨域資源共享的支持的討論，請參見這篇文章： Server-Side_Access_Control (CORS)。
 

簡單請求
 

某些請求不會觸發 CORS 預檢請求。本文稱這樣的請求爲「簡單請求」，請注意，該術語並不屬於 Fetch （其中定義了 CORS）規範。若請求知足全部下述條件，則該請求可視爲「簡單請求」：
 
 

 
 注意: 這些跨域請求與瀏覽器發出的其餘跨域請求並沒有二致。若是服務器未返回正確的響應首部，則請求方不會收到任何數據。所以，那些不容許跨域請求的網站無需爲這一新的 HTTP 訪問控制特性擔憂。 

 

 
 注意: WebKit Nightly 和 Safari Technology Preview 爲 
 Accept,  
 Accept-Language, 和  
 Content-Language 首部字段的值添加了額外的限制。若是這些首部字段的值是「非標準」的，WebKit/Safari 就不會將這些請求視爲「簡單請求」。WebKit/Safari 並無在文檔中列出哪些值是「非標準」的，不過咱們能夠在這裏找到相關討論： 
 Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language,  
 Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and  
 Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它瀏覽器並不支持這些額外的限制，由於它們不屬於規範的一部分。 

 

好比說，假如站點 http://foo.example 的網頁應用想要訪問 http://bar.other 的資源。http://foo.example 的網頁中可能包含相似於下面的 JavaScript 代碼：
 

 
 
var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/public-data/';
   
function callOtherDomain() {
  if(invocation) {    
    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}
 

 

客戶端和服務器之間使用 CORS 首部字段來處理跨域權限：
 

 

分別檢視請求報文和響應報文：
 

 
 
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
 

 

第 1~10 行是請求首部。第10行 的請求首部字段 Origin 代表該請求來源於 http://foo.exmaple。
 

第 13~22 行是來自於 http://bar.other 的服務端響應。
響應中攜帶了響應首部字段 Access-Control-Allow-Origin（第 16 行）。
使用 Origin 和 Access-Control-Allow-Origin 就能完成最簡單的訪問控制。
本例中，服務端返回的 Access-Control-Allow-Origin: * 代表，該資源能夠被任意外域訪問。
若是服務端僅容許來自 http://foo.example 的訪問，該首部字段的內容以下：
 

Access-Control-Allow-Origin: http://foo.example
 

如今，除了 http://foo.example，其它外域均不能訪問該資源（該策略由請求首部中的 ORIGIN 字段定義，見第10行）。
Access-Control-Allow-Origin 應當爲 * 或者包含由 Origin 首部字段所指明的域名。
 

預檢請求
 

與前述簡單請求不一樣，「需預檢的請求」要求必須首先使用 OPTIONS   方法發起一個預檢請求到服務器，以獲知服務器是否容許該實際請求。"預檢請求「的使用，能夠避免跨域請求對服務器的用戶數據產生未預期的影響。
 

當請求知足下述任一條件時，即應首先發送預檢請求：
 
 

 
 
注意: WebKit Nightly 和 Safari Technology Preview 爲Accept, Accept-Language, 和 Content-Language 首部字段的值添加了額外的限制。若是這些首部字段的值是「非標準」的，WebKit/Safari 就不會將這些請求視爲「簡單請求」。WebKit/Safari 並無在文檔中列出哪些值是「非標準」的，不過咱們能夠在這裏找到相關討論：Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它瀏覽器並不支持這些額外的限制，由於它們不屬於規範的一部分。
 

 

以下是一個須要執行預檢請求的 HTTP 請求：
 

 
 
var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
    
function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}
 

 

 
 

上面的代碼使用 POST 請求發送一個 XML 文檔，該請求包含了一個自定義的請求首部字段（X-PINGOTHER: pingpong）。另外，該請求的 Content-Type 爲 application/xml。所以，該請求須要首先發起「預檢請求」。
 

 

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
 

預檢請求完成以後，發送實際請求：
 

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]
 

瀏覽器檢測到，從 JavaScript 中發起的請求須要被預檢。從上面的報文中，咱們看到，第 1~12 行發送了一個使用 OPTIONS 方法的「預檢請求」。 OPTIONS 是 HTTP/1.1 協議中定義的方法，用以從服務器獲取更多信息。該方法不會對服務器資源產生影響。 預檢請求中同時攜帶了下面兩個首部字段：
 

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER
 

首部字段 Access-Control-Request-Method 告知服務器，實際請求將使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服務器，實際請求將攜帶兩個自定義請求首部字段：X-PINGOTHER 與 Content-Type。服務器據此決定，該實際請求是否被容許。
 

第14~26 行爲預檢請求的響應，代表服務器將接受後續的實際請求。重點看第 17~20 行：
 

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
 

首部字段 Access-Control-Allow-Methods 代表服務器容許客戶端使用 POST, GET 和 OPTIONS 方法發起請求。該字段與 HTTP/1.1 Allow: response header 相似，但僅限於在須要訪問控制的場景中使用。
 

首部字段 Access-Control-Allow-Headers 代表服務器容許請求中攜帶字段 X-PINGOTHER 與 Content-Type。與 Access-Control-Allow-Methods 同樣，Access-Control-Allow-Headers 的值爲逗號分割的列表。
 

最後，首部字段 Access-Control-Max-Age 代表該響應的有效時間爲 86400 秒，也就是 24 小時。在有效時間內，瀏覽器無須爲同一請求再次發起預檢請求。請注意，瀏覽器自身維護了一個最大有效時間，若是該首部字段的值超過了最大有效時間，將不會生效。
 

預檢請求與重定向
 

大多數瀏覽器不支持針對於預檢請求的重定向。若是一個預檢請求發生了重定向，瀏覽器將報告錯誤：
 

 
 
The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight
 

 

 
 
Request requires preflight, which is disallowed to follow cross-origin redirect
 

 

CORS 最初要求該行爲，不過在後續的修訂中廢棄了這一要求。
 

在瀏覽器的實現跟上規範以前，有兩種方式規避上述報錯行爲：
 

     
 
  • 在服務端去掉對預檢請求的重定向；
    •  
 
  • 將實際請求變成一個簡單請求。
    •  

 

若是上面兩種方式難以作到，咱們仍有其餘辦法：
 

     
 
  • 使用簡單請求模擬預檢請求，用以探查預檢請求是否重定向到其餘 URL（使用  Response.url 或 XHR.responseURL）；
    •  
 
  • 向上一步中得到的 URL 發起請求。
    •  

 

不過，若是請求因爲缺失 Authorization 字段而引發一個預檢請求，則這一方法將沒法使用。這種狀況只能由服務端進行更改。
 

附帶身份憑證的請求
 

Fetch 與 CORS 的一個有趣的特性是，能夠基於  HTTP cookies 和 HTTP 認證信息發送身份憑證。通常而言，對於跨域 XMLHttpRequest 或 Fetch 請求，瀏覽器不會發送身份憑證信息。若是要發送憑證信息，須要設置 XMLHttpRequest 的某個特殊標誌位。
 

本例中，http://foo.example 的某腳本向 http://bar.other 發起一個GET 請求，並設置 Cookies：
 

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}
 

第 7 行將 XMLHttpRequest 的 withCredentials 標誌設置爲 true，從而向服務器發送 Cookies。由於這是一個簡單 GET 請求，因此瀏覽器不會對其發起「預檢請求」。可是，若是服務器端的響應中未攜帶 Access-Control-Allow-Credentials: true ，瀏覽器將不會把響應內容返回給請求的發送者。
 

 

客戶端與服務器端交互示例以下：
 

GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain


[text/plain payload]
 

即便第 11 行指定了 Cookie 的相關信息，可是，若是 bar.other 的響應中缺失 Access-Control-Allow-Credentials: true（第 19 行），則響應內容不會返回給請求的發起者。
 

附帶身份憑證的請求與通配符
 

對於附帶身份憑證的請求，服務器不得設置 Access-Control-Allow-Origin 的值爲「*」。
 

這是由於請求的首部中攜帶了 Cookie 信息，若是 Access-Control-Allow-Origin 的值爲「*」，請求將會失敗。而將 Access-Control-Allow-Origin 的值設置爲 http://foo.example，則請求將成功執行。
 

另外，響應首部中也攜帶了 Set-Cookie 字段，嘗試對 Cookie 進行修改。若是操做失敗，將會拋出異常。
 

HTTP 響應首部字段EDIT
 

本節列出了規範所定義的響應首部字段。上一小節中，咱們已經看到了這些首部字段在實際場景中是如何工做的。
 

Access-Control-Allow-Origin
 

響應首部中能夠攜帶一個 Access-Control-Allow-Origin 字段，其語法以下:
 

Access-Control-Allow-Origin: <origin> | *
 

其中，origin 參數的值指定了容許訪問該資源的外域 URI。對於不須要攜帶身份憑證的請求，服務器能夠指定該字段的值爲通配符，表示容許來自全部域的請求。
 

例如，下面的字段值將容許來自 http://mozilla.com 的請求：
 

Access-Control-Allow-Origin: http://mozilla.com
 

若是服務端指定了具體的域名而非「*」，那麼響應首部中的 Vary 字段的值必須包含 Origin。這將告訴客戶端：服務器對不一樣的源站返回不一樣的內容。
 

Access-Control-Expose-Headers
 

Access-Control-Expose-Headers 首部字段指定了服務端容許的首部字段集合。
 

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
 

服務器容許請求中攜帶 X-My-Custom-Header 和 X-Another-Custom-Header 這兩個字段。
 

Access-Control-Max-Age
 

Access-Control-Max-Age 首部字段指明瞭預檢請求的響應的有效時間。
 

Access-Control-Max-Age: <delta-seconds>
 

delta-seconds 表示該響應在多少秒內有效。
 

Access-Control-Allow-Credentials
 

Access-Control-Allow-Credentials 首部字段用於預檢請求的響應，代表服務器是否容許 credentials 標誌設置爲 true 的請求。請注意：簡單 GET 請求不會被預檢；若是對此類請求的響應中不包含該字段，瀏覽器不會將響應返回給請求的調用者。
 

Access-Control-Allow-Credentials: true
 

上文已經討論了附帶身份憑證的請求。
 

Access-Control-Allow-Methods
 

Access-Control-Allow-Methods 首部字段用於預檢請求的響應。其指明瞭實際請求所容許使用的 HTTP 方法。
 

Access-Control-Allow-Methods: <method>[, <method>]*
 

相關示例見這裏。
 

Access-Control-Allow-Headers
 

Access-Control-Allow-Headers 首部字段用於預檢請求的響應。其指明瞭實際請求中容許攜帶的首部字段。
 

Access-Control-Allow-Headers: <field-name>[, <field-name>]*
 

HTTP 請求首部字段EDIT
 

本節列出了可用於發起跨域請求的首部字段。請注意，這些首部字段無須手動設置。 當開發者使用 XMLHttpRequest 對象發起跨域請求時，它們已經被設置就緒。
 

Origin
 

Origin 首部字段代表預檢請求或實際請求的源站。
 

Origin: <origin>
 

origin 參數的值爲源站 URI。它不包含任何路徑信息，只是服務器名稱。
 

 
 Note: 有時候將該字段的值設置爲空字符串是有用的，例如，當源站是一個 data URL 時。 

 

注意，無論是否爲跨域請求，ORIGIN 字段老是被髮送。
 

Access-Control-Request-Method
 

Access-Control-Request-Method 首部字段用於預檢請求。其做用是，將實際請求所使用的 HTTP 方法告訴服務器。
 

Access-Control-Request-Method: <method>
 

相關示例見這裏。
 

Access-Control-Request-Headers
 

Access-Control-Request-Headers 首部字段用於預檢請求。其做用是，將實際請求所攜帶的首部字段告訴服務器。
 

Access-Control-Request-Headers: <field-name>[, <field-name>]*
 

相關示例見這裏。
 

規範EDIT
 

 
  
  
 
   Specification 
   Status 
   Comment 
  
 
  
 
   Fetch
CORS		 
   Living Standard 
   New definition; supplants CORS specification. 
  
 
  
 
   CORS 
   Recommendation 
   Initial definition. 
  
 
  

 

瀏覽器兼容性EDIT
 

 
 

 
  
  
 
 
  
 
    
    
 
     Feature 
     Chrome 
     Firefox (Gecko) 
     Internet Explorer 
     Opera 
     Safari 
    
 
    
 
     Basic support 
     4 
     3.5 
     8 (via XDomainRequest)
10		 
     12 
     4 
    
 
    
  
 
 
 

 

 
 

注：
 

     
 
  • IE 10 提供了對規範的完整支持，但在較早版本（8 和 9）中，CORS 機制是藉由 XDomainRequest 對象完成的。
    •  
 
  • Firefox 3.5 引入了對 XMLHttpRequests 和 Web 字體的跨域支持（但最初的實現並不完整，這在後續版本中獲得完善）；Firefox 7 引入了對 WebGL 貼圖的跨域支持；Firefox 9 引入了對 drawImage 的跨域支持。
    •  

 

參見EDIT
 
 

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS
 

 
 

什麼是CORS?
 

 
 
Cross-origin resource sharing(跨域資源共享),是一個W3C標準,它容許你向一個不一樣源的服務器發出XMLHttpRequest請求,從而克服了ajax只能請求同源服務的限制.而且也能夠經過靈活的設置,來指定什麼樣的請求是能夠被受權的.
 

 

什麼是跨域?
 

假設你在http://xxx.com/test/下有一個js文件,從這個js裏發出一個ajax請求請求後端服務,按照以下狀況斷定:
 

 
  
  
 
   請求地址 
   緣由 
   結果 
  
 
  
  
  
 
   http://xxx.com/xxxx/action 
   同一域名,不一樣文件夾 
   非跨域 
  
 
  
 
   http://xxx.com/test/action 
   同一域名,同一文件夾 
   非跨域 
  
 
  
 
   http://a.xxx.com/test/action 
   不一樣域名,文件路徑相同 
   跨域 
  
 
  
 
   http://xxx.com:8080/test/action 
   同一域名,不一樣端口 
   跨域 
  
 
  
 
   https://xxx.com/test/action 
   同一域名,不一樣協議　 
   跨域 
  
 
  

 

還有那些其餘的跨域解決方案?
 

     
 
  •  
    JSONP : 動態添加一個<script>標籤，而script標籤的src屬性是沒有跨域的限制的。這樣說來，這種跨域方式其實與ajax XmlHttpRequest協議無關了,而缺點也很明顯,它只支持GET請求而不支持POST等其它類型的HTTP請求；它只支持跨域HTTP請求這種狀況，不能解決不一樣域的兩個頁面之間如何進行JavaScript調用的問題
     
    •  
 
  •  
    NGINX代理 : 經過一個代理服務器,將跨域的請求轉發,如:前端JS在http://www.demo.com/a.js,後端是http://www.abc.com/app/action,經過代理可將後端的地址轉換成http://www.demo/app/action,這樣,從前端發起的請求,就不存在跨域的狀況了
     
    •  

 

而後CORS是支持全部類型的HTTP請求,而且也只是服務端進行設置便可,可是缺點就是老的瀏覽器不支持CORS(如:IE7,7,8,等)
 

思路
 

CORS的響應頭
 

     
 
  •  
    Access-Control-Allow-Origin : 必須的,容許的域名,若是設置*,則表示接受任何域名
     
    •  
 
  •  
    Access-Control-Allow-Credentials : 非必須的,表示是否容許發送Cookie,注意,當設置爲true的時候,客戶端的ajax請求,也須要將withCredentials屬性設置爲true
     
    •  
 
  •  
    Access-Control-Expose-Headers : 非必須的,表示客戶端能拿到的header,默認狀況下XMLHttpRequest的getResponseHeader方法只能拿到幾個基本的header,若是有自定義的header要獲取的話,則須要設置此值
     
    •  
 
  •  
    Access-Control-Request-Method : 必須的,表示CORS上會使用到那些HTTP方法
     
    •  
 
  •  
    Access-Control-Request-Headers : 必須的,表示CORS上會有那些額外的的有信息
     
    •  

 

CORS將請求分爲兩種類型
 

兩種類型分別爲簡單請求和非簡單請求,同時知足如下兩大條件的請求被定義爲是簡單請求:
 

     
 
  •  
    請求方法是如下三種之一:
     
    •  
 
  •  
    HEAD
     
    •  
 
  •  
    GET
     
    •  
 
  •  
    POST
     
    •  
 
  •  
    HTTP頭信息不超出如下幾種字段:
     
    •  
 
  •  
    Accept
     
    •  
 
  •  
    Accept-Language
     
    •  
 
  •  
    Content-Language
     
    •  
 
  •  
    Last-Event-ID
     
    •  
 
  •  
    Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain
     
    •  

 

對於非簡單請求,瀏覽器會自動發一個預檢請求,這個請求是OPTIONS方法的,主要是詢問服務器當前請求是否在容許範圍內
 

實現
 

1.方式A:使用@CrossOrigin來標記指定的方法(小範圍跨域)
 

 
 
@RequestMapping(value = "add", method = RequestMethod.GET) @CrossOrigin(methods = { RequestMethod.GET, RequestMethod.POST }, origins = "*") public RestResponse<Integer> add(Integer a, Integer b) { return new RestResponse<>(demoService.add(a, b)); }
 

 

2.方式B:使用spring boot的默認配置來設定全局跨域
 

 
 
endpoints.cors.allow-credentials= endpoints.cors.allowed-headers= endpoints.cors.allowed-methods=GET endpoints.cors.allowed-origins= endpoints.cors.exposed-headers= endpoints.cors.max-age=1800
 

 

3.方式C:使用WebMvcConfigurer自定義配置跨域
 

定義CorsRegistrationConfig類
 

 
 
public static class CorsRegistrationConfig { //描述 : 掃描地址 private String mapping = "/**"; //描述 : 容許證書 private Boolean allowCredentials = null; //描述 : 容許的域 private String allowedOrigins = "*"; //描述 : 容許的方法 private String allowedMethods = "POST,GET,DELETE,PUT"; //描述 : 容許的頭信息 private String allowedHeaders = "*"; .........省略 }
 

 

定義CorsConfig類
 

 
 
@Configuration @ConfigurationProperties(prefix = "org.itkk.cors") @Validated public class CorsConfig { //描述 : 跨域信息 @NotNull private Map<String, CorsRegistrationConfig> config; .....省略 }
 

 

定義重寫addCorsMappings方法
 

 
 
@Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurerAdapter() { @Override public void addCorsMappings(CorsRegistry registry) { //掃描地址 if (!CollectionUtils.isEmpty(config)) { Iterator<String> keys = config.keySet().iterator(); while (keys.hasNext()) { String key = keys.next(); CorsRegistrationConfig item = config.get(key); CorsRegistration cr = registry.addMapping(item.getMapping()); if (item.getAllowCredentials() != null) { cr.allowCredentials(item.getAllowCredentials()); } if (StringUtils.isNotBlank(item.getAllowedOrigins())) { String[] allowedOriginArray = item.getAllowedOrigins().split(","); cr.allowedOrigins(allowedOriginArray); } if (StringUtils.isNotBlank(item.getAllowedMethods())) { String[] allowedMethodArray = item.getAllowedMethods().split(","); cr.allowedMethods(allowedMethodArray); } if (StringUtils.isNotBlank(item.getAllowedHeaders())) { String[] allowedHeaderArray = item.getAllowedHeaders().split(","); cr.allowedHeaders(allowedHeaderArray); } } } } }; }
 

 

配置文件,可根據不一樣的mapping設置不一樣的cors規則
 

 
 
org.itkk.cors.config.demo.mapping=/** org.itkk.cors.config.demo.allowCredentials= org.itkk.cors.config.demo.allowedOrigins= org.itkk.cors.config.demo.allowedMethods= org.itkk.cors.config.demo.allowedHeaders=
 

 

使用jquery,在跨域場景下進行測試
 

 
 
$(function(){ $.ajax({ url:'http://127.0.0.1:8080/demo/c', headers:{ 'aheader':'111' }, type:'GET', dataType:'json', success:function(data){ console.log(1); console.log(data); console.log(2); } }); });
 

 

代碼倉庫 (博客配套代碼)
 
 

結束
 

演示了單spring boot的應用的,在後續的章節中,會找機會寫一下在微服務場景下(spring cloud)的跨域設置
 

http://www.cnblogs.com/itkk/p/7447118.html


 

運行時何處會添加responseHeader的Origin？
 

prehandle:
 

RequestMapping方法(該方法執行結束後添加)
 

posthandle
 

aftercomplish
 

crossOrigin註解中的method，若是寫了會覆蓋requestMethod中指定的，不寫的話默認就是requestMethod中指定的。
 

request中默認會設定本身的Origin。
 

如上連接官方文檔所說，只有簡單請求才會觸發preflight.
 

因此postman測試本地程序時：
 

get方法，以及body爲空的post,設置的跨域不起做用，request中header的origin爲空。就跟沒設置同樣。 瀏覽器get也不起做用 
body包含了文件的post,設置的跨域起做用。此時request中header的origin不爲空，response也不爲空。（能夠查看本地的origin）
 

注意maxAge，若是某個地方未能跨域訪問，因爲其緩存，致使其它原本能跨域訪問的也不能訪問了。
 

/** 匹配的是 /開始的全部路徑及文件，包括//domain,也包括/domain 
/* 匹配的是/開始的，包括/domain,但不包括//domain，也不包括/domain/file
 

因此若是設置了但不起做用，極可能是如下兩個緣由：
 

全局設定時路徑沒匹配對
多個路徑的狀況下有遺漏的路徑沒有設定，緩存的緣由。
 

https://blog.csdn.net/yangyi1101/article/details/77307312


Using pre-signed URLs to upload a file to a private S3 bucket
 

https://sanderknape.com/2017/08/using-pre-signed-urls-upload-file-private-s3-bucket/


        

            

        	





    

		

            
相關文章

            

                

                

                    

                

            


            
相關標籤/搜索

            
        


    

        

            

        

        

        
        

        

        

    




	

    





    

    	

    

        每日一句
    

    
    
    	每一个你不满意的现在，都有一个你没有努力的曾经。
    







    

    


    



    

        本站公眾號
    

    

           歡迎關注本站公眾號,獲取更多信息

        
    




    

    




	


	







    

        聯繫我們
        最近搜索
        最新文章
        
        沪ICP备13005482号-10

            MyBatis教程
            SQL 教程
            MySQL教程
            Java 教程
            Thymeleaf 教程
            Hibernate教程
            Spring教程 
            Redis教程