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, 随后的‘简单‘get
或post
请求还是会发送,但是浏览器不会允许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请求类型(比如get
,post
)。
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。
你可以写一个自己的平台,或者使用一个已有的解决方案,比如
记住,这种方法可能存在安全风险,如果你想要支持验证的话。
更多关于 CORS
如果你想学更多关于CORS的细节,我推荐你去查看更加细节化的MDN article.