CORS详解

Posted 2020-08-26 最骚的就是你

介绍

由于同源策略的缘故，以往我们跨域请求，会使用诸如JSON-P（不安全）或者代理（设置代理和维护繁琐）的方式。而跨源资源共享（Cross-Origin Resource Sharing）是一个W3C规范，其建立在XMLHttpRequest对象之上，允许开发人员像使用同源请求一样的规则，在浏览器端发送跨域请求。

CORS的使用场景很简单。例如，站点bob.com想要请求获取alice.com的数据，由于同源策略缘故，这种情况在传统请求中是不被允许的。然而，bob.com通过CORS请求alice.com，并在alice.com响应头中添加少许特殊的响应头，就可以达到bob.com获取到alice.com数据的目的。

正如你上面看到的例子，要实现CORS，需要客户端和服务端的共同协调。幸运的是，如果你是客户端开发人员，很多具体细节对于你来说是屏蔽的。好了，接下来我们将介绍客户端怎样发起跨域请求，以及服务端如何设置，从而达到支持CORS的目的。

发起一个CORS请求

该小节讲解了如何使用javascript发起一个跨域请求。

-创建XMLHttpRequest对象-

浏览器支持CORS情况，如下：

.Chrome 3+

.Firefox 3.5+

.Opera 12+

.Safari 4+

.Internet Explorer 8+

浏览器支持CORS情况，更多见http://caniuse.com/#search=cors

Chrome，Firefox，Opera 和 Safari都是使用XMLHttpRequest2对象。Internet Explorer使用了类似的对象XDomainRequest，其工作原理和XMLHttpRequest大致相同，但增加了额外的安全防范措施。

由于浏览器的差异，首先，你需要根据浏览器的不同，创建一个合适的请求对象。Nicholas Zakas写了一个简单的辅助方法，来屏蔽掉浏览器的差异，如下：

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if("withCredentials" in xhr){
        //检查XHLHttpRequest对象是否有"withCredentials"属性
        //"withCredentials"属性仅存在于XMLHttpReqeust2对象中
        xhr.open(method, url, true);
    }else if(typeof XDomainRequest !="undefined"){
        //否则，检查XDomainRequest
        //XDomainRequest仅存在IE中，且通过其发起CORS请求
        xhr = new XDomainRequest();
        xhr.open(method, url);
    }else{
        //否则，CORS不被该浏览器支持
        xhr = null;
    }
    return xhr;
}
var xhr = createCORSRequest(\'GET\', url);
if(!xhr){
    throw new Error(\'CORS not supported\');    
}

-事件处理-

最初的XMLHttpRequest对象只有一个事件句柄：

onreadystatechange，处理所有的响应。虽然onreadystatechange仍然可用，但是XMLHttpRequest2引入了更多新的事件句柄，如下：

事件句柄	描述
onloadstart*	当请求发起时
onprogress	当加载和发送数据时
onabort*	当请求被中断时。例如，调用abort()方法
onerror	当请求失败时
onload	当请求成功时
ontimeout	当请求时间超过开发者设定时间时
onloadend*	当请求完成时（成功或失败）

上述，凡是带有星号（*）的事件句柄，IE的XDomainRequest都不支持。

来源：http://www.w3.org/TR/XMLHttpRequest2/#events

在大多数情况下，我们至少会使用onload和onerror事件：

xhr.onload = function(){
    var responseText = xhr.responseText;
    console.log(responseText);
    //处理响应
};
xhr.onerror = function(){
    console.log(\'There was an error!\');
}

当请求出现错误时，浏览器并不能很友好地报告出具体的错误。比如，Firefox对所有的错误都会报告0状态和空状态文本。浏览器也能通过日志反馈错误信息，但是信息却不能被JavaScript获取。当处理onerror事件句柄时，你会知道有错误出现，除此之外，一无所获。

-withCredentials-

标准的CORS请求，默认情况下是不会发送或者设置cookie值的。为了在请求时，附带cookies，我们需要设置XMLHttpRequest的withCredentials属性为true：

xhr.withCredentials = true;

为了让其运作，服务端也必须在响应头中设置Access-Control-Allow-Credentials为true，开启credentials。如下：

Access-Control-Allow-Credentials: true;

设置withCredentials属性后，远程域请求时会带上所有cookies，以及设置它们。注意，这些cookie值仍然遵守同源策略，所以我们的JavaScript代码仍然不能从document.cookie或者响应头中获取cookie，它们仅仅被远程域控制。

-发送请求-

现在我们的CORS请求设置完毕，我们通过调用send()方法，即可发起该请求，如下：

xhr.send();

如果该请求有请求体，那么作为send方法中的参数，发送即可。

客户端的CORS就这样啦！假设服务端已经设置好了CORS，当服务端返回响应后，我们的onload事件句柄就会被触发，就像你熟悉的标准同源XHR请求一样。

-端到端例子-

下面就是一个完整的CORS示例。运行示例并在浏览器调试器中查看实际请求操作。

// 创建XHR 对象.
function createCORSRequest(method, url) {  
  var xhr = new XMLHttpRequest();
  if ("withCredentials" in xhr) {
    // XHR for Chrome/Firefox/Opera/Safari.
    xhr.open(method, url, true);
  } else if (typeof XDomainRequest != "undefined") {
    // XDomainRequest for IE.
    xhr = new XDomainRequest();
    xhr.open(method, url);
  } else {
    // 不支持CORS.
    xhr = null;
  }
  return xhr;
}

// 辅助函数：解析响应内容中的title标签
function getTitle(text) {  
  return text.match(\'<title>(.*)?</title>\')[1];
}

// 发起CORS请求.
function makeCorsRequest() {  
  // html5 Rocks支持 CORS.
  var url = \'http://updates.html5rocks.com\';

  var xhr = createCORSRequest(\'GET\', url);
  if (!xhr) {
    alert(\'CORS not supported\');
    return;
  }

  // 响应处理.
  xhr.onload = function() {
    var text = xhr.responseText;
    var title = getTitle(text);
    alert(\'Response from CORS request to \' + url + \': \' + title);
  };

  xhr.onerror = function() {
    alert(\'Woops, there was an error making the request.\');
  };

  xhr.send();
}

服务端配置CORS

CORS最繁重的处理是在浏览器和服务器之间。当浏览器发送一个CORS请求时，会添加一些额外的响应头，有时还会发送额外的请求。这些额外的步骤对于客户端人员来说，是透明的（但是我们可以通过一个包分析器去发现，例如Wireshark）。

浏览器制造商负责浏览器端的实现。该小节将阐述，服务端如何设置它的头部，从而达到支持CORS的目的。

-CORS请求类型-

跨域请求有两种形式：

1、  简单请求

2、  非简单请求

简单请求满足以下条件：

.HTTP请求方法（区分大小写）为以下之一：

。HEAD

。GET

。POST

.HTTP头部匹配（不区分大写小）为以下：

。Accept

。Accept-Language

。Content-Language

。Last-Event-ID

。Content-Type，但是赋值仅为以下之一：

    -application/x-www-form-urlencoded

    -multipart/form-data

    -text/plain

简单请求的特征如上所诉，因为它们不需要使用CORS就可以在浏览器中发起跨域请求了。例如，JSON-P发起GET请求跨域，又如HTML利用POST提交表单。

其他任何请求，只要不满足以上条件的，都是非简单请求，且发起非简单请求时，在浏览器和服务器之间需要额外的通信（又叫预请求）。好了，下面我们就一同进入跨域之旅吧。

-处理一个简单请求-

我们从客户端发起一个简单请求开始。下面的代码展示了如何利用JavaScript发起一个简单请求GET，以及浏览器实际发出的HTTP请求。

JavaScript:

var url = \'http://api.alice.com/cors\';
var xhr = createCORSRequest(\'GET\', url);
xhr.send();

HTTP请求：

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

值得注意的是，一个有效的CORS请求，总是包含一个Origin头部，而这个Origin头部又是浏览器自动添加的，用户操作不了。且，这个Origin头部的值是由协议（例如http），域名（例如bob.com）和端口（仅当不是默认端口时，包含，例如81）组成，如http://api.alice.com。

但也要注意，如果一个请求包含Origin头部，未必就是一个跨域请求。虽然所有的CORS请求都会包含一个Origin头部，但是一些同源请求可能也会包含它。例如，Firefox在发起同源请求时，不会包含一个Origin头部，但是Chrome和Safari下，除发起同源GET请求不会包含Origin头部外，发起同源POST/PUT/DELETE请求时，都会包含Origin头部。例如，下面就是一个包含Origin头部的同源请求：

POST /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.bob.com

好消息是，对于同源请求，浏览器不会期望服务器返回CORS响应头。因此不管是否有CORS标头，同源请求的响应都是直接发送给用户。然而，如果我们服务器代码返回一个错误，假设源信息Origin不在服务器请求列表中，那么要在头部Origin中包含请求源。

下面是一个关于CORS有效的服务器响应:

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true;
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

所有和CORS相关的头部都是以"Access-Control-"开头。更多，见下：

Access-Control-Allow-Origin(必须)-该请求头必须包含在所有合法的CORS响应头中；否则，省略该响应头会导致CORS请求失败。该值要么与请求头Origin的值一样（如上述例子），要么设置成星号‘*’，以匹配任意Origin。如果你想任何站点都能获取到你的数据，那么就使用‘*’吧。但是，如果你想有效的控制，就将该值设置为一个实际的值。

Access-Control-Allow-Credentials(可选)-默认情况下，发送CORS请求，cookies是不会附带发送的。但是，通过使用该响应头就可以让cookies包含在CORS请求中。注意，该响应头只有唯一的合法值true（全部小写）。如果你不需要cookies值，就不要包含该响应头了，而不是将该响应头的值设置成false。该响应头Access-Control-Allow-Credentials需要与XMLHttpRequest2对象的withCredentials属性配合使用。当这两个属性同时设置为true时，cookies才能附带。例如，withCredentials被设置成true，但是响应头中不包含 Access-Control-Allow-Credentials响应头，那么该请求就会失败（反之亦然）。发送CORS请求时，最好不要携带cookies，除非你确定你想在请求中包含cookie。

Access-Control-Expose-Headers(可选)-XMLHttpRequest2对象有一个getResponseHeader()方法，该方法返回一个特殊响应头值。在一个CORS请求中，getResponseHeader()方法仅能获取到简单的响应头，如下：

.Cache-Control

.Content-Language

.Content-Type

.Expires

.Last-Modified

.Pragma

如果你想客服端能够获取到其他的头部信息，你必须设置Access-Control-Expose-Headers响应头。该响应头的值可以为响应头的名称，不过需要利用逗号隔开，这样客服端就能通过getResponseHeader方法获取到了。

-处理一个非简单请求-

在上面，我们一起学习了简单请求GET，但是倘若我们想做更多的事情呢？比如，我们想使用PUT或者DELETE请求，又或者我们想使用Content-Type:application/json来支持JSON。那么，我们就需要掌握该节讲述的‘非简单请求’了。

我们在使用非简单请求时，表面上看起来客户端只发送了一个请求，但实际上，要完成一次非简单请求，客户端在私底下是要向服务器发起两次请求的。第一次请求，是向服务器确认权限，一旦被授权，则发起第二次请求（真正意义上的数据请求）。且，第一次请求也可以被缓存，所以不是每次我们发起非简单请求，都会预请求一次。

例，非简单请求如下：

JavaScript:

var url = \'http://api.alice.com/cors\';
var xhr = createCORSRequest(\'PUT\', url);
xhr.setRequestHeader(\'X-Custom-Header\', \'value\');
xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

和简单请求一样，浏览器自动将Origin头部信息添加到每个请求中，包括这里的预检查请求。预检查请求用的方法是OPTIONS（所以请确保我们的服务器能够响应该方法）。且，它也包含两个特殊的头部信息，如下：

Access-Control-Request-Method：该字段表示实际的CORS是什么HTTP方法，如上述的PUT方法，且该字段是必须的，即使是简单请求的方法（GET，POST，HEAD）。

Access-Control-Request-Headers：该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，如上述的X-Custom-Header。

在上面我们已经提到，预检查请求的目的是向服务器确认实际的 CORS请求权限，那么它是如何检查的呢。

其实，就是验证预检查请求中的两个特殊的请求头（Access-Control-Request-Method和Access-Control-Request-Headers）来裁定的。服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就做如下响应：

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8

Access-Control-Allow-Origin(必须)—和简单请求一样，预检查响应也必须包含该头部，具体描述详见简单请求中的Access-Control-Allow-Origin。

Access-Control-Allow-Methods (必须)--它是逗号分隔的一个字符串，值由HTTP方法构成，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。因为已提过预检查请求可以被缓存，所以这样可以避免多次"预检"请求。

Access-Control-Allow-Headers--如果浏览器请求包括Access-Control-Request-Headers字段，则该字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段，因为可以缓存嘛。

Access-Control-Allow-Credentials(可选)—和简单请求一样，详见上述简单请求中的该字段。

Access-Control-Max-Age(可选)--如果每次发起一个非简单的CORS请求，都暗地向服务器发送两次请求，那代价也太大了点，所以该字段可以指定预检查请求可以被缓存多少秒。

一旦预检查得到授权信息，那么浏览器就会发送真正的跨域请求了。且，请求和服务器响应与简单CORS请求一样。

第二次请求(实际CORS请求)，如下：

PUT /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

响应如下：

Access-Control-Allow-Origin: http://api.bob.com
Content-Type: text/html; charset=utf-8

如果服务端想要拒绝该CORS请求，那么它可以返回一个普通的响应（如HTTP 200），即不包含任何属于CORS的头部信息。如果预检查请求没有被审核通过，即没有任何关于CORS头部信息的响应，那么浏览器是不会发起第二次实际的请求的，如下服务器响应预检查请求：

//错误-没有CORS头部信息，所以表示是一个无效请求
Content-Type: text/html; charset=utf-8

且会触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息：