一文了解 CORS 跨域访问机制及 COS 上的配置方式。

背景

早期为了避免 CSRF(跨站请求伪造) 攻击,浏览器引入了 “同源策略” 机制。如果两个 URL 的协议,主机名(域名/IP),端口号一致,则视为这两个 URL “同源”,属于同一个 “域”,否则视为 “非同源”,即 “跨域”。浏览器会主动拦截跨域的 AJAX 请求,以规避安全风险。

“同源策略” 固然提升了请求的安全性,但有时我们需要跨域请求其他域名下的资源,例如在业务域名下请求 COS 的 API 接口,或者读取 COS 存储桶中文件的内容,进行一些逻辑处理。

浏览器支持一种跨域的访问验证的机制,即 CORS(Cross-Origin Resource Sharing 跨源资源共享)。该机制允许服务端通过返回特定的 HTTP 头部来告知浏览器是否拦截跨域请求。

COS 支持用户在存储桶中配置 “跨域访问 CORS” 规则,以此放行一些合法的跨域请求。

业务场景

下面我们以 博客网站开发 为例,带您了解如何在 COS 配置 CORS 规则。

用户正在开发一个博客网站,为此他将一批 markdown 文件上传到 COS,对每个 markdown 文件设置了自定义头部 x-cos-meta-keywords 表示该文章的关键词,并将文件权限设置为公有读私有写。

网站的前端 JS 脚本通过浏览器向 COS 发起 AJAX 请求,读取响应的内容以及头部信息,将内容转换为 HTML 文本,解析 x-cos-meta-keywords 中包含的关键词,分别挂载到页面对应的 DOM 节点下,其请求过程如下图所示:

用户网站的地址是 http://example.com,Markdown 文件的地址是 https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md

很显然,这是在 http://example.com 下对 https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com 发起请求,涉及跨域。

不出意外地,浏览器拦截了该请求,打开浏览器的 Console 栏可以看到如下报错:

Access to XMLHttpRequest at 'https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md'
from origin 'http://example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

GET https://bucketname-1250000000.cos.ap-guangzhou.myqcloud.com/test.md net::ERR_FAILED

CORS 跨域访问机制

为了解决该问题,我们需要理解浏览器的 CORS 跨域访问机制。浏览器将 CORS 请求分成两类:简单请求(simple request)和非简单请求(not-so-simple request),只要同时满足以下两大条件,就属于 “简单请求”,否则就属于 “非简单请求”。

请求方法是以下三种方法之一:

  • HEAD
  • GET
  • POST

HTTP 的头信息不超出以下几种字段:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type:只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain

对于简单请求,浏览器会在请求时携带 Origin 头部,声明该请求来自哪个 “域”,服务端通过 Access-Control-Allow-Origin 和Access-Control-Allow-Methods 响应头来告知浏览器允许的 “域” 和 “HTTP 动词”。

对于非简单请求,浏览器会在实际请求前发起一次 “预检请求(preflight request)”,用于询问服务端是否允许跨域,如果不允许,则不发起实际请求。

预检请求使用 OPTIONS 动词,并携带 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 请求头部,来声明 “当前的域”、“实际请求使用的 HTTP 动词” 和 “实际请求将携带的头部” 等信息。

服务端通过 Access-Control-Allow-Origin、 Access-Control-Allow-Methods 、Access-Control-Allow-Headers、Access-Control-Allow-Credentials 响应头来告知浏览器 “允许的域”、“允许的所有 HTTP 动词”、“允许携带的所有 HTTP 头部” 以及 “是否允许携带鉴权信息(Cookie,Authorization 头部等)”。

同时,为了避免频繁发起跨域检测,服务端会返回 Access-Control-Max-Age 来声明本次跨域检测的有效期,浏览器会缓存检测结果,并在有效期内使用浏览器缓存。

服务端还可以通过返回 Access-Control-Expose-Headers 头部来告知浏览器,哪些特定响应头允许暴露给 AJAX 请求。通常只有 Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma 允许暴露,其他头部需要服务端特定声明。

浏览器会根据预检请求响应的 CORS 相关头部进行判断,只有实际请求的 Origin,Methods,Headers 等均符合要求,才会发起实际请求。

在 COS 配置 CORS 跨域规则

了解了 CORS 跨域访问机制后,我们看看用户需要配置的哪些 CORS 响应头部。

  • 需配置Access-Control-Allow-Origin,必须包含 http://example.com,表示允许 http://example.com 对 COS 的跨域访问。
  • 需配置Access-Control-Allow-Methods,必须包含GET方法。
  • 需配置Access-Control-Expose-Headers,必须包含自定义头部 x-cos-meta-keywords,表示允许暴露该响应头部。

于是用户进入 COS 控制台,点击进入存储桶,在左侧的 “安全设置” 中选择 “跨域访问 CORS 设置”,点击添加规则,按如下规则填写:

  • 来源 Origin:填入 http://example.com(也可以填写 *,代表允许所有域)
  • 操作 Methods:勾选 GET
  • Allow-Headers:设置为 *,代表请求允许携带任何头部
  • Expose-Headers:添加 x-cos-meta-keywords

实际填写如下图所示,点击确定。

再次尝试刚刚的跨域请求,可以看到,跨域请求成功,并返回了文件内容以及自定义头部信息。

更进一步,用户还希望在网站上添加 “保存文章”,“删除文章” 等功能,为了降低开发成本,我们推荐其使用 cos-js-sdk-v5。为避免后续其他请求的跨域问题,我们推荐进行如下设置:

  • 来源 Origin:填入 http://example.com(填写您的域名,须包含协议)
  • 操作 Methods:勾选 PUT、GET、POST、DELETE、HEAD
  • Allow-Headers:设置为 *,代表请求允许携带任何头部
  • Expose-Headers:添加 ETag,x-cos-request-id 头部,确保 SDK 可以读取到需要的头部
  • 超时 Max-Age:设置为 600,让浏览器缓存跨域检测结果,过期时间为 600 秒

CDN 上配置 CORS 规则

如果开通了 CDN 服务,并且设置 COS 为 CDN 的源站,由于 CDN 会缓存 COS 的响应结果,包括跨域响应头部。通过 CDN 域名访问 COS 上的文件时,如果希望响应的跨域头部为最新配置,可以在 CDN 控制台的 “Response Header 配置” 中设置 CORS 相关跨域头部,如下图所示:

可以看到,跨域请求 CDN 加速域名下的资源成功,响应的跨域头部和 CDN 控制台配置的一致。

结语

全文通过博客网站开发,浏览器主动拦截跨域的 AJAX 请求的场景,详细介绍了 CORS 跨域访问机制,以及如何在 COS 和 CDN 上配置 CORS 跨域规则。

此外,对象存储 COS 的 CORS 跨域机制基于存储桶可以配置多条跨域访问规则,允许 Web 应用服务器进行跨域访问控制,使得跨域数据传输得以安全进行,简单易用,无需额外的第三方工具操作。满足客户 Web 应用需要跨域访问存储桶资源的需求,帮助您构建内容丰富的 Web 应用。

COS 一直在不断地丰富产品特性,帮助用户更加轻松的使用对象存储 COS,让用户聚焦于数据内容,为业务赋能,释放数据价值。

版权声明:本文为cloudstorageangel原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/cloudstorageangel/p/14336566.html