![](/trylang-blog/images/theme/empty.jpg)
跨源资源共享(CORS)
跨源资源共享(CORS)
image-20210225194116399
跨源资源共享 (CORS) (或通俗地译为跨域资源共享)是一种基于HTTP 头的机制,该机制通过允许服务器标示除了它自己以外的其它origin(域,协议和端口),这样浏览器可以访问加载这些资源。
预检机制:跨源资源共享有一种预检机制。浏览器跨源向服务器发起请求时,首先还需要向服务器发起一个“预检”请求,在预检中,浏览器发送的头中标示有HTTP方法和真实请求中会用到的头。
出于安全性,浏览器限制脚本内发起的跨源HTTP请求。 例如,XMLHttpRequest和Fetch API遵循同源策略。 这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源,除非响应报文包含了正确CORS响应头。
什么情况下需要 CORS ?
这份 cross-origin sharing standard 允许在下列场景中使用跨站点 HTTP 请求:
- 前文提到的由
XMLHttpRequest
或 Fetch 发起的跨源 HTTP 请求。 - Web 字体 (CSS 中通过
@font-face
使用跨源字体资源),因此,网站就可以发布 TrueType 字体资源,并只允许已授权网站进行跨站调用。 - WebGL 贴图
- 使用
drawImage
将 Images/video 画面绘制到 canvas
功能概述
跨源资源共享标准新增了一组 HTTP 首部字段,允许服务器声明哪些源站通过浏览器有权限访问哪些资源。
另外,规范要求,对那些可能对服务器数据产生副作用的 HTTP 请求方法(特别是 GET
以外的 HTTP 请求,或者搭配某些 MIME 类型的 POST
请求),
浏览器必须首先使用 OPTIONS
方法发起一个预检请求(preflight request),从而获知服务端是否允许该跨源请求。服务器确认允许之后,才发起实际的 HTTP 请求。在预检请求的返回中,服务器端也可以通知客户端,是否需要携带身份凭证(包括 Cookies 和 HTTP 认证相关数据)。
三个控制场景
1. 简单请求
某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”。
使用下列方法之一:
除了被用户代理自动设置的首部字段(例如
Connection
,User-Agent
)和在 Fetch 规范中定义为禁用首部名称的其他首部,允许人为设置的字段为 Fetch 规范定义的
对 CORS 安全的首部字段集合。该集合为:
Accept
Accept-Language
Content-Language
Content-Type
(需要注意额外的限制)DPR
Downlink
Save-Data
Viewport-Width
Width
Content-Type
的值仅限于下列三者之一:text/plain
multipart/form-data
application/x-www-form-urlencoded
请求中的任意
XMLHttpRequestUpload
对象均没有注册任何事件监听器;XMLHttpRequestUpload
对象可以使用XMLHttpRequest.upload
属性访问。请求中没有使用
ReadableStream
对象。
注意: WebKit Nightly 和 Safari Technology Preview 为
Accept
,Accept-Language
, 和Content-Language
首部字段的值添加了额外的限制。如果这些首部字段的值是“非标准”的,WebKit/Safari 就不会将这些请求视为“简单请求”。WebKit/Safari 并没有在文档中列出哪些值是“非标准”的。
2. 预检请求
“预检请求”必须首先使用 OPTIONS
方法发起一个预检请求到服务器,以获知服务器是否允许该实际请求。”预检请求“的使用,可以避免跨域请求对服务器的用户数据产生未预期的影响。
如下是一个需要执行预检请求的 HTTP 请求:
1 |
|
上面的代码使用 POST 请求发送一个 XML 文档,该请求包含了一个自定义的请求首部字段(X-PINGOTHER: pingpong)。另外,该请求的 Content-Type 为 application/xml。因此,该请求需要首先发起“预检请求”。
preflight_correct
1 |
|
预检请求完成之后,发送实际请求:
1 |
|
浏览器检测到,从 JavaScript 中发起的请求需要被预检。从上面的报文中,我们看到,第 1~12 行发送了一个使用 OPTIONS 方法的“
预检请求”。
OPTIONS 是 HTTP/1.1 协议中定义的方法,用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段:
1 |
|
首部字段 Access-Control-Request-Method
告知服务器,实际请求将使用 POST 方法。首部字段 Access-Control-Request-Headers
告知服务器,实际请求将携带两个自定义请求首部字段:X-PINGOTHER
与 Content-Type
。服务器据此决定,该实际请求是否被允许。
第1426 行为预检请求的响应,表明服务器将接受后续的实际请求。重点看第 1720 行:
1 |
|
首部字段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 小时。在有效时间内,浏览器无须为同一请求再次发起预检请求。请注意,浏览器自身维护了一个最大有效时间,如果该首部字段的值超过了最大有效时间,将不会生效。
3. 附带身份凭证的请求
XMLHttpRequest
或 Fetch 与 CORS 的一个有趣的特性是,可以基于 HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言,对于跨源 XMLHttpRequest
或 Fetch 请求,浏览器不会发送身份凭证信息。如果要发送凭证信息,需要设置 XMLHttpRequest
的某个特殊标志位。
本例中,http://foo.example 的某脚本向 http://bar.other 发起一个GET 请求,并设置 Cookies:
1 |
|
第 7 行将 XMLHttpRequest
的 withCredentials
标志设置为 true
,从而向服务器发送 Cookies。因为这是一个简单 GET 请求,所以浏览器不会对其发起“预检请求”。但是,如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true
,浏览器将不会把响应内容返回给请求的发送者。
cred-req-updated
附带身份凭证的请求与通配符
对于附带身份凭证的请求,服务器不得设置 Access-Control-Allow-Origin
的值为“*
”。
这是因为请求的首部中携带了 Cookie
信息,如果 Access-Control-Allow-Origin
的值为“*
”,请求将会失败。而将 Access-Control-Allow-Origin
的值设置为 http://foo.example
,则请求将成功执行。
另外,响应首部中也携带了 Set-Cookie 字段,尝试对 Cookie 进行修改。如果操作失败,将会抛出异常。
第三方 cookies
注意在 CORS 响应中设置的 cookies 适用一般性第三方 cookie 策略。在上面的例子中,页面是在 foo.example
加载,但是第 20 行的 cookie 是被 bar.other
发送的,如果用户设置其浏览器拒绝所有第三方 cookies,那么将不会被保存。
HTTP 响应首部字段
1. Access-Control-Allow-Origin
响应首部中可以携带一个 Access-Control-Allow-Origin
字段,其语法如下:
1 |
|
其中,origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求,服务器可以指定该字段的值为通配符,表示允许来自所有域的请求。
例如,下面的字段值将允许来自 http://mozilla.com 的请求:
1 |
|
如果服务端指定了具体的域名而非“*”,那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端:服务器对不同的源站返回不同的内容。
2. Access-Control-Expose-Headers
译者注:在跨源访问时,XMLHttpRequest对象的getResponseHeader()方法只能拿到一些最基本的响应头,Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma,如果要访问其他头,则需要服务器设置本响应头。
Access-Control-Expose-Headers
头让服务器把允许浏览器访问的头放入白名单,例如:
1 |
|
这样浏览器就能够通过getResponseHeader访问X-My-Custom-Header
和 X-Another-Custom-Header
响应头了。
3. Access-Control-Max-Age
Access-Control-Max-Age
头指定了preflight请求的结果能够被缓存多久,请参考本文在前面提到的preflight例子。
1 |
|
delta-seconds
参数表示preflight请求的结果在多少秒内有效。
4. Access-Control-Allow-Credentials
Access-Control-Allow-Credentials
头指定了当浏览器的credentials
设置为true时是否允许浏览器读取response的内容。当用在对preflight预检测请求的响应中时,它指定了实际的请求是否可以使用credentials
。请注意:简单 GET 请求不会被预检;如果对此类请求的响应中不包含该字段,这个响应将被忽略掉,并且浏览器也不会将相应内容返回给网页。
1 |
|
上文已经讨论了附带身份凭证的请求。
5. Access-Control-Allow-Methods
Access-Control-Allow-Methods
首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。
1 |
|
相关示例见这里。
6. Access-Control-Allow-Headers
Access-Control-Allow-Headers
首部字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。
1 |
|
HTTP 请求首部字段
本节列出了可用于发起跨源请求的首部字段。请注意,这些首部字段无须手动设置。 当开发者使用 XMLHttpRequest 对象发起跨源请求时,它们已经被设置就绪。
1. Origin
Origin
首部字段表明预检请求或实际请求的源站。
1 |
|
origin 参数的值为源站 URI。它不包含任何路径信息,只是服务器名称。
Note: 有时候将该字段的值设置为空字符串是有用的,例如,当源站是一个 data URL 时。
注意,在所有访问控制请求(Access control request)中,Origin
首部字段总是被发送。
2. Access-Control-Request-Method
Access-Control-Request-Method
首部字段用于预检请求。其作用是,将实际请求所使用的 HTTP 方法告诉服务器。
1 |
|
相关示例见这里。
3. Access-Control-Request-Headers
Access-Control-Request-Headers
首部字段用于预检请求。其作用是,将实际请求所携带的首部字段告诉服务器。
1 |
|
相关示例见这里。
- 本文作者:Jane
- 本文链接:http://trylang.github.io/trylang-blog/2021/02/25/http/%E8%B7%A8%E6%BA%90%E8%B5%84%E6%BA%90%E5%85%B1%E4%BA%AB%EF%BC%88CORS%EF%BC%89/index.html
- 版权声明:本博客所有文章均采用 BY-NC-SA 许可协议,转载请注明出处!
![](/trylang-blog/images/theme/empty.jpg)