0

这是一个我认为我理解的概念,但最近发现我错了。我查看了互联网上的所有内容,并找到大量小细节和代码片段的示例,但我仍然缺乏对它的阻止以及为什么阻止它以及为什么阻止它的理解。所以这更多的是要求高层次的解释而不是问题。交叉来源xhr和同源政策

不管怎么说,这里就是我想我了解:

比方说,我有域A.com和域B.com。每个人都拥有自己的IP地址的apache服务器。 我从域A.com加载一个HTML文件到浏览器中。浏览器执行POST XMLHttpRequest到B.com/doStuff.php,由于设置了相同的域策略而失败。

所以: 谁是同域名政策是相关的?我认为答案是B.com/doStuff.php ...对不对?因此,当A发送请求时,B检查请求标头的来源,并说“哎呀,不同的域,不会听你的”。或者A发送请求,B响应指定“same-domain-policy”的头部,然后浏览器检查该请求,因为指定了same-domain-policy,并且A请求头部的域不匹配来自B的请求BROWSER拒绝发送xhr?

如果是这样的话,似乎不允许跨原点请求的一点是,因为“我不想比我之外的任何人访问我的API”。这就是全部?因为你不想用某种认证来解决这个问题吗?难道有人只是构造一个假源头的HTTP请求(简单地说谎)?

或者这是否应该保护用户?如果是这样的话,如何防止他们调用你的API来保护任何人?

我很困惑...

+0

不会抢夺使用URL,例如停止机器,卷曲,它只是试图阻止基于浏览器的抓取。要阻止非js威胁,您必须​​进行身份验证。关键是一个网站的内容不能通过未经签名的JS重新嵌入,而不需要你明确地允许它。 – dandavis

+0

@dandavis不是那么容易回避吗?只需要你的服务器获得它的javascript请求(例如curl),然后将它传递回javascript ...有什么意义? – Phildo

+0

重点是控制和问责:服务器/ php代码注册到信用卡,普通旧网页不是。在你的例子中,执行curl的服务器可以很容易地识别和阻止,但是如果流量来自广告注入的javascript,请求可能来自任何地方... – dandavis

回答

0

的想法是,你不希望通过JavaScript从服务器A访问服务器B。如果您正在使用API​​进行交互,则可以使用JavaScript调用您自己的服务器的后端代码,然后再调用其他服务器。

+0

但为什么? “我不希望有人从JavaScript访问我的API,但是如果他们从PHP中获得它,那么这似乎是一个完全肤浅的理由来证明这个基础设施...... – Phildo

1
Who's same-domain-policy is relevant? 

服务器接收到该请求决定。

... the BROWSER refuses to send out the xhr? 

否,服务器拒绝回应。更准确地说,在现代浏览器中,它由preflighted requests完成。这意味着对于每个跨源请求,首先由浏览器自动发送一个OPTIONS请求,该浏览器的头部与预期请求的头部完全相同,但没有请求主体。服务器只响应头文件。响应中的访问控制标题将让客户端浏览器知道请求是否会根据服务器的策略得到满足。从某种意义上说,浏览器阻止了请求,但仅仅是因为它已经与服务器交换了一个请求/响应对,并且知道没有任何要求尝试请求。如果您在这种情况下伪造请求,服务器仍然拒绝提供服务。

+0

好吧,这样才有意义。谢谢你澄清! 但是,我然后纠正这整个事情的唯一目的是不允许人们访问您的API,但只有通过特定的JavaScript? (IE-你的API仍然可以被其他任何东西访问,而JavaScript不能做到这一点的唯一原因是因为浏览器不支持JS编辑它的源头的方式)。谁在保护?您的API仍然可以访问 - 它只需要一个简单的解决方法(告诉您的服务器进行调用,然后将它传回给您的js)。 – Phildo

+0

“仅仅需要一个简单的解决方法”是一个不太小的“正义”,仅仅是这种区分形成了基本的客户端网络安全的基础。一个PHP服务器可以关闭,一个胭脂脚本更难以扑灭,并且造成比curl或php任何人以及他们的兄弟可以写的更大的问题。 – dandavis

+0

@dandavis - 基本的客户端网络安全的基石?!如果存在一种解决方法,我(一个被允许的新手)可以很容易地利用(这又可能不是这种情况 - 我仍然在等待/希望能够纠正,但是...),客户端网站被搞砸了!充其量,这似乎只是懒惰黑客的前线障碍......?如果这就是全部,那就这样吧。但我觉得我一直听到喋喋不休,好像这种事情是一件大事。 (我的意思是没有不尊重 - 我只是在努力去掌握所有这些,并且确信有些东西我仍然缺少......) – Phildo