cross origin resource sharing - cors

Preflight request

一个 CORS 预检请求是用于检查服务器是否支持 CORS 即跨域资源共享。

它一般是用了以下几个 HTTP 请求首部的 OPTIONS 请求:Access-Control-Request-Method 和 Access-Control-Request-Headers,以及一个 Origin 首部。

当有必要的时候,浏览器会自动发出一个预检请求;所以在正常情况下,前端开发者不需要自己去发这样的请求。

这里先看个简单的例子,下文有详细说明预检请求过程,一个客户端可能会在实际发送一个 DELETE 请求之前,先向服务器发起一个预检请求,用于询问是否可以向服务器发起一个 DELETE 请求:

OPTIONS /resource/fooAccess-Control-Request-Method: DELETEAccess-Control-Request-Headers: origin, x-requested-withOrigin: https://foo.bar.org

如果服务器允许,那么服务器就会响应这个预检请求,并且其响应首部 Access-Control-Allow-Methods 会将 DELETE 包含在其中:

HTTP/1.1 200 OKContent-Length: 0Connection: keep-aliveAccess-Control-Allow-Origin: https://foo.bar.orgAccess-Control-Allow-Methods: POST, GET, OPTIONS, DELETEAccess-Control-Max-Age: 86400

跨域资源共享 - CORS

跨域资源共享(CORS) 是一种机制,它使用额外的 HTTP 头来告诉浏览器,让运行在一个 origin (domain) 上的 Web 应用被准许访问来自不同源服务器上的指定的资源。当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时,资源会发起一个跨域 HTTP 请求。

比如,站点 http://domain-a.com 的某 HTML 页面通过 <img> 的 src 请求 http://domain-b.com/image.jpg 。网络上的许多页面都会加载来自不同域的 CSS 样式表,图像和脚本等资源。

出于安全原因,浏览器限制从脚本内发起的跨源 HTTP 请求(译者注:这段描述不准确,并不一定是浏览器限制了发起跨站请求,也可能是跨站请求可以正常发起,但是返回结果被浏览器拦截了)。例如,XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源,除非响应报文包含了正确 CORS 响应头。

跨域资源共享( CORS )机制允许 Web 应用服务器进行跨域访问控制,从而使跨域数据传输得以安全进行。现代浏览器支持在 API 容器中(例如 XMLHttpRequest 或 Fetch)使用 CORS,以降低跨域 HTTP 请求所带来的风险。

什么情况下需要 CORS

跨域资源共享标准( cross-origin sharing standard )允许在下列场景中使用跨域 HTTP 请求:

  1. 前文提到的由 XMLHttpRequest 或 Fetch 发起的跨域 HTTP 请求。
  2. Web 字体 (CSS 中通过 @font-face 使用跨域字体资源), 因此,网站就可以发布 TrueType 字体资源,并只允许已授权网站进行跨站调用。
  3. WebGL 贴图
  4. 使用 drawImage 将 Images/video 画面绘制到 canvas
  5. 样式表(使用 CSSOM)

本文概述了跨域资源共享机制及其所涉及的 HTTP 头。

功能概述

跨域资源共享标准新增了一组 HTTP 首部字段,允许服务器声明哪些源站通过浏览器有权限访问哪些资源。另外,规范要求,对那些可能对服务器数据产生副作用的 HTTP 请求方法(特别是 GET 以外的 HTTP 请求,或者搭配某些 MIME 类型的 POST 请求),浏览器必须首先使用 OPTIONS 方法发起一个预检请求(preflight request),从而获知服务端是否允许该跨域请求。服务器确认允许之后,才发起实际的 HTTP 请求。在预检请求的返回中,服务器端也可以通知客户端,是否需要携带身份凭证(包括 Cookies 和 HTTP 认证相关数据)。

CORS 请求失败会产生错误,但是为了安全,在 JavaScript 代码层面是无法获知到底具体是哪里出了问题。你只能查看浏览器的控制台以得知具体是哪里出现了错误。

接下来的内容将讨论相关场景,并剖析该机制所涉及的 HTTP 首部字段。

若干访问控制场景

这里,我们使用三个场景来解释跨域资源共享机制的工作原理。这些例子都使用 XMLHttpRequest 对象。

本文中的 JavaScript 代码片段都可以从 http://arunranga.com/examples/access-control/ 获得。另外,使用支持跨域 XMLHttpRequest 的浏览器访问该地址,可以看到代码的实际运行结果。

关于服务端对跨域资源共享的支持的讨论,请参见这篇文章: Server-Side_Access_Control (CORS)。

简单请求

某些请求不会触发 CORS 预检请求。本文称这样的请求为简单请求,请注意,该术语并不属于 Fetch (其中定义了 CORS)规范。若请求满足所有下述条件,则该请求可视为简单请求

使用下列方法之一:

  1. GET
  2. HEAD
  3. POST

Fetch 规范定义了对 CORS 安全的首部字段集合,不得人为设置该集合之外的其他首部字段。该集合为:

  1. Accept
  2. Accept-Language
  3. Content-Language
  4. Content-Type (需要注意额外的限制)
  5. DPR
  6. Downlink
  7. Save-Data
  8. Viewport-Width
  9. Width

Content-Type 的值仅限于下列三者之一:

  1. text/plain
  2. multipart/form-data
  3. application/x-www-form-urlencoded

请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器;XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问。

请求中没有使用 ReadableStream 对象。

注意: 这些跨域请求与浏览器发出的其他跨域请求并无二致。如果服务器未返回正确的响应首部,则请求方不会收到任何数据。因此,那些不允许跨域请求的网站无需为这一新的 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 首部字段来处理跨域权限:

分别检视请求报文和响应报文:

1234567891011121314151617181920
GET /resources/public-data/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-aliveReferer: http://foo.example/examples/access-control/simpleXSInvocation.htmlOrigin: http://foo.exampleHTTP/1.1 200 OKDate: Mon, 01 Dec 2008 00:23:53 GMTServer: Apache/2.0.61Access-Control-Allow-Origin: *Keep-Alive: timeout=2, max=100Connection: Keep-AliveTransfer-Encoding: chunkedContent-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 的访问,该首部字段的内容如下:

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

现在,除了 http://foo.example ,其它外域均不能访问该资源(该策略由请求首部中的 ORIGIN 字段定义,见第 10 行)。Access-Control-Allow-Origin 应当为 * 或者包含由 Origin 首部字段所指明的域名。

预检请求

与前述简单请求不同,需预检的请求 要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器,以获知服务器是否允许该实际请求。预检请求 的使用,可以避免跨域请求对服务器的用户数据产生未预期的影响。

当请求满足下述任一条件时,即应首先发送预检请求:

使用了下面任一 HTTP 方法:

  1. PUT
  2. DELETE
  3. CONNECT
  4. OPTIONS
  5. TRACE
  6. PATCH

人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为:

  1. Accept
  2. Accept-Language
  3. Content-Language
  4. Content-Type (需要注意额外的限制)
  5. DPR
  6. Downlink
  7. Save-Data
  8. Viewport-Width
  9. Width

Content-Type 的值不属于下列之一:

  1. application/x-www-form-urlencoded
  2. multipart/form-data
  3. text/plain

请求中的 XMLHttpRequestUpload 对象注册了任意多个事件监听器。

请求中使用了 ReadableStream 对象。

注意: 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。因此,该请求需要首先发起预检请求

1234567891011121314151617181920212223242526
OPTIONS /resources/post-here/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-aliveOrigin: http://foo.exampleAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: X-PINGOTHER, Content-TypeHTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400Vary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 0Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-Type: text/plain

预检请求完成之后,发送实际请求:

12345678910111213141516171819202122232425262728293031
POST /resources/post-here/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-aliveX-PINGOTHER: pingpongContent-Type: text/xml; charset=UTF-8Referer: http://foo.example/examples/preflightInvocation.htmlContent-Length: 55Origin: http://foo.examplePragma: no-cacheCache-Control: no-cache<?xml version="1.0"?><person><name>Arun</name></person>HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:40 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://foo.exampleVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 235Keep-Alive: timeout=2, max=99Connection: Keep-AliveContent-Type: text/plain[Some GZIP'd payload]

浏览器检测到,从 JavaScript 中发起的请求需要被预检。从上面的报文中,我们看到,第 1~12 行发送了一个使用 OPTIONS 方法的预检请求。 OPTIONS 是 HTTP/1.1 协议中定义的方法,用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段:

Access-Control-Request-Method: POSTAccess-Control-Request-Headers: X-PINGOTHER, Content-Type

首部字段 Access-Control-Request-Method 告知服务器,实际请求将使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服务器,实际请求将携带两个自定义请求首部字段:X-PINGOTHER 与 Content-Type。服务器据此决定,该实际请求是否被允许。

第 14~26 行为预检请求的响应,表明服务器将接受后续的实际请求。重点看第 17~20 行:

Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400

首部字段 Access-Control-Allow-Methods 表明服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求。该字段与 HTTP/1.1Allow: 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 最初要求该行为,不过在后续的修订中废弃了这一要求。

在浏览器的实现跟上规范之前,有两种方式规避上述报错行为:

  1. 在服务端去掉对预检请求的重定向;
  2. 将实际请求变成一个简单请求。

如果上面两种方式难以做到,我们仍有其他办法:

  1. 发出一个简单请求(使用 Response.url 或 XHR.responseURL)以判断真正的预检请求会返回什么地址。
  2. 发出另一个请求(真正的请求),使用在上一步通过 Response.url 或 XMLHttpRequest.responseURL 获得的 URL。

不过,如果请求是由于存在 Authorization 字段而引发了预检请求,则这一方法将无法使用。这种情况只能由服务端进行更改。

附带身份凭证的请求

Fetch 与 CORS 的一个有趣的特性是,可以基于 HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言,对于跨域 XMLHttpRequest 或 Fetch 请求,浏览器不会发送身份凭证信息。如果要发送凭证信息,需要设置 XMLHttpRequest 的某个特殊标志位。

本例中,http://foo.example 的某脚本向 http://bar.other 发起一个 GET 请求,并设置 Cookies:

1234567891011
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 ,浏览器将不会把响应内容返回给请求的发送者。

客户端与服务器端交互示例如下:

12345678910111213141516171819202122232425262728293031
GET /resources/access-control-with-credentials/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Connection: keep-aliveReferer: http://foo.example/examples/credential.htmlOrigin: http://foo.exampleCookie: pageAccess=2HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:34:52 GMTServer: 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.2X-Powered-By: PHP/5.2.6Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Credentials: trueCache-Control: no-cachePragma: no-cacheSet-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMTVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 106Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-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 响应首部字段

本节列出了规范所定义的响应首部字段。上一小节中,我们已经看到了这些首部字段在实际场景中是如何工作的。

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

译者注:在跨域访问时,XMLHttpRequest 对象的 getResponseHeader()方法只能拿到一些最基本的响应头,Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma,如果要访问其他头,则需要服务器设置本响应头。

Access-Control-Expose-Headers 头让服务器把允许浏览器访问的头放入白名单,例如:

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

这样浏览器就能够通过 getResponseHeader 访问 X-My-Custom-Header 和 X-Another-Custom-Header 响应头了。

Access-Control-Max-Age

Access-Control-Max-Age 头指定了 preflight 请求的结果能够被缓存多久,请参考本文在前面提到的 preflight 例子。

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

delta-seconds 参数表示 preflight 请求的结果在多少秒内有效。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials 头指定了当浏览器的 credentials 设置为 true 时是否允许浏览器读取 response 的内容。当用在对 preflight 预检测请求的响应中时,它指定了实际的请求是否可以使用 credentials。

请注意:简单 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 请求首部字段

本节列出了可用于发起跨域请求的首部字段。请注意,这些首部字段无须手动设置。 当开发者使用 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>]*

server CORS process flowchart

CORS POST example

fetch('https://httpbin.org/post',        {method: 'POST', headers: new Headers({'Content-Type': 'application/json'}), body: JSON.stringify({a: 1})})    .then(response => response.json())    .then(json => console.log(json));

上述请求可在浏览器控制台测试,OPTIONS 请求头如下:

Access-Control-Request-Headers: content-typeAccess-Control-Request-Method: POSTDNT: 1Origin: http://test.4e00.comReferer: http://test.4e00.com/blog/web/2019/04/09/http-cross-origin-resource-sharing-cors.htmlUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

OPTIONS 请求服务器回响应头如下:

Access-Control-Allow-Credentials: trueAccess-Control-Allow-Headers: content-typeAccess-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONSAccess-Control-Allow-Origin: http://test.4e00.comAccess-Control-Max-Age: 3600Allow: POST, OPTIONSConnection: keep-aliveContent-Length: 0Content-Type: text/html; charset=utf-8Date: Wed, 09 Apr 2019 11:29:49 GMTServer: nginx

OPTIONS 预检请求合法,然后发起的 HTTP POST 请求头如下:

content-type: application/jsonDNT: 1Origin: http://test.4e00.comReferer: http://test.4e00.com/blog/web/2019/04/09/http-cross-origin-resource-sharing-cors.htmlUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

返回结果如下:

{  "args": {},  "data": "{\"a\":1}",  "files": {},  "form": {},  "headers": {    "Accept": "*/*",    "Accept-Encoding": "gzip, deflate, br",    "Accept-Language": "en-US,en;q=0.9,zh;q=0.8,zh-CN;q=0.7,zh-TW;q=0.6,ja;q=0.5,sv;q=0.4,hu;q=0.3,fr;q=0.2,sn;q=0.1,pt;q=0.1",    "Content-Length": "7",    "Content-Type": "application/json",    "Dnt": "1",    "Host": "httpbin.org",    "Origin": "http://test.4e00.com",    "Referer": "http://test.4e00.com/blog/web/2019/04/09/http-cross-origin-resource-sharing-cors.html",    "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"  },  "json": {    "a": 1  },  "origin": "10.87.121.107",  "url": "https://httpbin.org/post"}

Spring boot application return 403 for CORS OPTIONS

一个跨域 POST 请求至后端 nginx,然后转发给 spring boot 应用,浏览器控制台抛错如下:

OPTIONS http://www.example.com/cors/post/request net::ERR_ABORTED 403Access to XMLHttpRequest at 'http://www.example.com/cors/post/request' from origin 'http://test.4e00.com' has been blocked by CORS policy:Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Tomcat log

spring boot 应用的 tomcat 日志 localhost-access.log 中可以看到返回的状态码就是 403,因为 OPTIONS 的 preflight 请求失败了,所以后面的 POST 请求并没有实际发送给服务器。

127.0.0.1 - - [09/Apr/2019:16:48:48 +0800] "OPTIONS /partner/login HTTP/1.0" 403 20 "http://test.4e00.com""Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36" 55

解决方法

这个问题一般来说是通过配置 spring boot 应用本身的设置,以达到跨域访问的效果,解决方法可参考 CORS preflight request fails due to a standard header 这个帖子。

我这里只是测试使用,因为中间是经过 nginx 反向代理的,所以直接通过 nginx 配置覆盖 spring boot tomcat 返回的 403 状态,绕过这个问题,即允许所有的跨域请求,包括数据修改的 POST 请求,nginx 配置部分如下:

location / {    proxy_pass http://127.0.0.1:8080/;    add_header Access-Control-Allow-Origin $http_origin;    add_header Access-Control-Allow-Methods GET,POST,OPTIONS;    add_header Access-Control-Allow-Credentials true;    add_header Access-Control-Allow-Headers DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type;    proxy_set_header X-Real-IP $remote_addr;    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;    proxy_set_header Host $http_host;    if ($request_method = OPTIONS) {        return 204; # 用这里覆盖 spring boot tomcat 返回的 403 状态    }}

References

  1. HTTP 访问控制 - CORS
  2. Cross-Origin Resource Sharing - CORS
  3. Preflight request
  4. Why is an OPTIONS request sent and can I disable it
  5. CORS preflight request fails due to a standard header