CORS试图解决的问题是什么?

Cod*_*ein 25 same-origin-policy cors

我一直在阅读CORS它是如何工作的,但我发现很多事情令人困惑.例如,关于诸如此类的事情有很多细节

用户Joe正在使用浏览器BrowserX从中获取数据site.com,而数据又发送请求spot.com.为此,spot有特殊标题... yada yada yada

没有太多背景,我不明白为什么网站不会让某些地方的请求.我的意思是,他们的存在是为了回应请求,不是吗?为什么某些人的请求不被允许?

它真的很感激解决问题的一个很好的解释(或一个链接)CORS.

所以问题是,

CORS解决的问题是什么?

Han*_*ney 21

通过JavaScript(AKA AJAX)从页面发起请求的Web浏览器的默认行为是它们遵循同源策略.这意味着只能通过AJAX将请求发送到同一个域(或子域).对完全不同的域的请求将失败.

存在此限制是因为您的浏览器在其他域发出的请求会随身携带您的Cookie,这通常意味着您将登录到其他网站.因此,如果没有同源,任何站点都可以托管在stackoverflow.com上调用注销的JavaScript,它会将您注销.现在想象一下当我们谈论社交网络,银行网站等时的复杂性.

因此,所有浏览器都只是将基于脚本的网络调用限制在自己的域中,以使其简单安全.

www.x.com上的站点X无法向www.y.com上的站点Y发出AJAX请求,仅向*.x.com发出

有一些已知的解决方法(例如JSONP在请求中不包含cookie),但这些不是永久解决方案.

CORS允许这些跨域请求发生,但只有当每一方都选择进入CORS支持时.

  • 在 MDN Access Cotrol 文档中,带有凭据的 GET 请求不会进行预检。但是,如果响应标头不包含 Access-Control-Allow-Credentials: true,则调用客户端将无法使用响应。如果 POST(带有凭据的简单 POST 请求 - 内容类型可能是表单数据)请求的行为也相同,则存在 POST 可能更改服务器状态的风险,尽管响应可能无法提供给客户端。这个假设正确吗?或者带有预检凭证的 POST 请求? (3认同)
  • 好吧,所以是浏览器设置了这些规则。如果是这样,那么服务器端的“Access-Control-Allow-Origin”是怎么回事?如果浏览器不允许,跨源请求如何到达那里? (2认同)

aps*_*ers 15

首先,我们来谈谈相同的原产地政策.我将引用我之前的答案:

发明了同源策略,因为它阻止来自一个网站的代码访问另一个站点上的凭据限制内容.默认情况下,Ajax请求与目标站点授予的任何auth cookie一起发送.

例如,假设我意外加载http://evil.com/,它发送请求http://mail.google.com/.如果SOP没有到位,并且我已登录Gmail,则脚本evil.com可以看到我的收件箱.如果网站evil.com想要加载mail.google.com没有我的cookie,它可以只使用代理服务器; 公共内容mail.google.com不是秘密(但mail.google.com使用我的cookie访问时的内容是秘密).

(请注意,我已经说过"凭据限制内容",但当网站仅对某些IP地址可见时,它也可能是受拓扑限制的内容.)

但是,有时候,它并没有evil.com试图窥视您的收件箱.有时,它只是一个有用的网站(比方说http://goodsite.foo),试图使用来自其他来源的公共API(比方说http://api.example.com).努力工作的程序员api.example.com 希望所有的起源都能自由访问他们网站的内容.在这种情况下,API服务器api.example.com可以使用CORS头来允许goodsite.foo(或任何其他请求源)访问其API响应.

所以,总的来说,我们在默认情况下是跨域访问是一件坏事(认为有人试图读取收件箱)承担,但也有情况下,这是一个很好的事情(觉得一个网站试图访问公共API) .当请求的站点希望它发生时,CORS允许好的情况发生.