跨源资源共享(CORS)

概念

跨源资源共享 (CORS) (或通俗地译为跨域资源共享)是一种基于HTTP 头的机制,该机制通过允许服务器标示除了它自己以外的其它origin(域,协议和端口),这样浏览器可以访问加载这些资源。跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求,该机制通过浏览器发起一个到服务器托管的跨源资源的"预检"请求。在预检中,浏览器发送的头中标示有HTTP方法和真实请求中会用到的头。

什么情况下需要 CORS ?

允许在下列场景中使用跨站点 HTTP 请求:

  • 前文提到的由 XMLHttpRequest 或 Fetch 发起的跨源 HTTP 请求。
  • Web 字体 (CSS 中通过 @font-face 使用跨源字体资源)。
  • WebGL 贴图
  • 使用 drawImage 将 Images/video 画面绘制到 canvas

功能概述

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

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

简单请求

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

  • 使用下列方法之一:
    • GET
    • HEAD
    • POST
  • 除了被用户代理自动设置的首部字段(例如 Connection ,User-Agent)和可人为设置的以下字段:
    • 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 对象均没有注册任何事件监听器。
  • 请求中没有使用 ReadableStream 对象。

服务端设置以下响应头可允许跨域请求

// 该资源可以被任意外域访问
header("Access-Control-Allow-Origin:*");
// 除了http://foo.example,其它外域均不能访问该资源
header("Access-Control-Allow-Origin:http://foo.example");

预检请求

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

浏览器检测到,从 JavaScript 中发起的请求需要被预检。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。服务器据此决定,该实际请求是否被允许。

预检请求的响应:

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

分别表明允许的域、请求方法、首部字段、同一请求预检请求有效期(有效时间内,浏览器无须为同一请求再次发起预检请求,请注意,浏览器自身维护了一个最大有效时间,如果该首部字段的值超过了最大有效时间,将不会生效。)

附带身份凭证的请求与通配符

withCredentials: true,对于附带身份凭证的请求,服务器不得设置 Access-Control-Allow-Origin 的值为“*”。这是因为请求的首部中携带了 Cookie 信息,如果 Access-Control-Allow-Origin 的值为“*”,请求将会失败。而将 Access-Control-Allow-Origin:http://foo.example,则请求将成功执行。另外,响应首部中也携带了 Set-Cookie 字段,尝试对 Cookie 进行修改。如果操作失败,将会抛出异常。

注意在 CORS 响应中设置的 cookies 适用一般性第三方 cookie 策略。即用户如果设置其浏览器拒绝所有第三方 cookies,那么将不会被保存。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
CORS(跨站资源共享)是一种用于在浏览器中进行跨域请求的机制。当浏览器发起跨域请求时,会先发送一个预检请求(OPTIONS请求)来验证服务器是否允许该跨域请求。如果预检请求的验证失败,就会出现CORS原始验证失败的情况。 CORS原始验证失败可能有以下几种原因: 1. 服务器未正确设置Access-Control-Allow-Origin响应头:对于附带身份凭证的请求,服务器不得设置Access-Control-Allow-Origin的值为“*”,而应该设置为请求源的具体值或允许的域名列表。 2. 服务器未正确设置Access-Control-Allow-Methods响应头:该响应头用于指定服务器支持的请求方法。如果服务器不支持预检请求中指定的请求方法,就会导致CORS原始验证失败。 3. 服务器未正确设置Access-Control-Allow-Headers响应头:该响应头用于指定服务器支持的请求头。如果服务器不支持预检请求中指定的请求头,就会导致CORS原始验证失败。 4. 服务器未正确设置Access-Control-Allow-Credentials响应头:如果请求附带了身份凭证(如cookie、HTTP认证等),服务器需要设置该响应头为true,表示允许跨域请求携带身份凭证。 5. 请求中的Content-Type不符合预检请求中的Content-Type:如果预检请求中指定了Content-Type,那么实际请求的Content-Type必须与之一致,否则会导致CORS原始验证失败。 如果出现CORS原始验证失败,你可以通过以下步骤来解决问题: 1. 检查服务器的响应头是否正确设置了Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers和Access-Control-Allow-Credentials。 2. 检查请求中的Content-Type是否与预检请求中的Content-Type一致。 3. 检查是否有其他安全机制(如防火墙、代理等)阻止了跨域请求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值