阅读 1187

[译] 理解CORS这一篇就够了

credit:https://medium.com/@baphemot

译自:https://medium.com/@baphemot/understanding-cors-18ad6b478e2b



                                                   “呃。。还行, 但不够”


如果你经常跟AJAX call打交道,那么你肯定遇到过下面这个错误。


如果你看到这条消息,意味着响应失败了,但你还是能在Console里的Network标签下,看到返回的数据。

那么,这里到底是怎么一回事呢?

跨源资源共享(CORS)

你所遇到的这种行为就是浏览器跨域的实现。

考虑到安全问题,在跨域标准化之前,如果你想调用一个节点在不同域的API, 是不存在的。这种调用,会因为 Same-Origin 政策被阻止。

设计CORS这种机制是为了,第一,使你所发出的请求能代表你自身; 第二, 阻止那些流氓JS发出的请求; 第三,这种机制会被激活,无论何时你发送请求到:

1). 不同的域名。(eg. 应用在 example.com 调用 api.com)

2). 不同的子域名。(eg. 应用在 example.com 调用 api.com)

3). 不同的端口。(eg. 应用在 example.com 调用 example.com:3001)

4). 不同的协议。(eg. 应用在 example.com 调用 example.com)

通过这种机制,我们能够阻止黑客的脚本攻击,以防当你登陆,比如银行网站,的时候替换你的验证信息。

如果你的浏览器尝试发起一个‘不简单’的请求(比如: 一个请求包含了cookies, 或者 Content-type 不是application/x-ww-form-urlencoded, multipart/form-data 或者 text-plain )这时候会调用有一种叫做 预检(preflight)的机制,然后会发送一个options请求到服务器。如果服务器的响应,没有携带特定的headers, 随后的‘简单‘getpost请求还是会发送,但是浏览器不会允许JS去访问的收到的数据。

如果你明确想要添加cookies,自定义headers和其他一些features,那这个请求就不再是一个‘简单’请求。那么服务器就不会合理地响应,请求也不会被发送。


Access-Control-Allow-What?

CORS使用很少的HTTP请求头(在请求和响应里都是),但是有一点你必须明白,而且有能力去在工作中应用:

Access-Control-Allow-Origin

这个请求头一般会被服务器端返回,它的值代表了哪些域名你有权可以访问。 它的值可以为:

  • *允许访问任何域
  • 一个安全验证过的域名(eg. example.com)

如果你请求客户端传一些用作验证的请求头,比如cookies, 那么你就不能将Access-Control-Allow-Origin的值设定为*—必须是安全验证过的域名才可以!

Access-Control-Allow-Credentials

如果一个服务器支持通过cookies来验证,那么必须要在响应里带上这个请求头。

True是其唯一有有效的值。

Access-Control-Allow-Headers

一个逗号分隔的list,存放代表服务器愿意支持的请求头。(eg. 比如x-authentication-token, 你需要将其包含在ACA header里, 返回给前面提到的options请求, 否则你的请求会被blocked)

Access-Control-Expose-Headers

跟上面相似,这个请求头包含一系列用户可用的headers,这些headers会出现在真实响应里,而且客户端是可以使用的。其他的所有header会被blocked。

Access-Control-Allow-Methods

这个比较简单,存放所有服务端支持的HTTP请求类型(比如getpost)。

Origin

客户端请求头的一部分,其值包含客户端app启动处的域名。 出于安全考虑,浏览器将不允许你去重写这个值。


如何消除‘CORS’错误

你不得不承认CORS并不是一种‘错误’。它是一种预期的机制为了去保护用户,你,还有你发送请求的目标网站。

有时候缺乏合理的请求头是客户端的一种错误的行为(eg. 缺少验证信息比如API key)。

这里我将给你一些方法去“解决错误”,选择哪种方法,这取决于你所应用的场景:

A - 我开发前端,后端我认识,听我的 ;)

嗯这当然是最好的情况, 你就可以去实现合理的CORS响应在你所请求的服务器端。如果一个API正在使用node的express框架,你只要用一下cors的包就行了。如果你想使你的网站更加合理安全,你可能要考虑使用一个白名单给Access-Control-Allow-Origin请求头。

B - 我开发前端,后端我不熟,暂时需要一个临时的解决方案 :)

这是第二好的情况,因为这就是A情况,只不过有一些时间限制。如果你想临时解决这个问题,你可以让你的浏览器忽略CORS机制,举个栗子,使用ACAO Chrome插件,或者在用Chome的时候跑一下下面的flags:

chrome --disable-web-security --user-data-dir复制代码

重要:请记住这条命令会应用于所有网站,并且存在于整个浏览器会话中。请小心使用。

另一个路子就是,你可以使用devServer.proxy(假设你使用webpack去serve你的app)或者使用一个 CORS-as-a-service 解决方案,比如cors-anywhere.herokuapp.com/

C - 我开发前端,我想要调后端? 不存在的 :`(

好吧,现在事情就变得复杂了。首先,你应该可能需要搞清,为什么服务器端没有发送一个正确的请求头。

可能它们不允许使用第三方的库的app去访问?可能它们的API只给服务器端的应用使用, 而不是浏览器?可能你在请求时没有发送用于验证的token?

如果你仍然认为你有能够通过浏览器得到数据,你应该去写一个自己的代理,存在于浏览器应用和API之间,就像我们在方案B中所做的一样。


                                        Adding a proxy in the middle

这个代理服务器,不是必须和你的应用跑在相同的域上。只要使得这个代理服务器,在与客户端交流时支持CORS就可以。在与API交流时不是必须要支持CORS。

你可以写一个自己的平台,或者使用一个已有的解决方案,比如

www.npmjs.com/package/cor…

记住,这种方法可能存在安全风险,如果你想要支持验证的话。


更多关于 CORS

如果你想学更多关于CORS的细节,我推荐你去查看更加细节化的MDN article.


关注下面的标签,发现更多相似文章
评论