同源政策
我想创建一个关于 HTML/JS同源策略的社区 wiki ,希望能帮助任何搜索此主题的人。这是 SO 上搜索次数最多的主题之一,并且没有统一的 wiki,所以我在这里 :)
同源策略可防止从一个源加载的文档或脚本从另一个源获取或设置文档的属性。该政策可追溯到 Netscape Navigator 2.0。
您最喜欢的绕过同源策略的一些方法是什么?
请保持示例详细,最好还链接您的来源。
我想创建一个关于 HTML/JS同源策略的社区 wiki ,希望能帮助任何搜索此主题的人。这是 SO 上搜索次数最多的主题之一,并且没有统一的 wiki,所以我在这里 :)
同源策略可防止从一个源加载的文档或脚本从另一个源获取或设置文档的属性。该政策可追溯到 Netscape Navigator 2.0。
请保持示例详细,最好还链接您的来源。
document.domain
方法请注意,这是一个 iframe 方法,它将 document.domain 的值设置为当前域的后缀。如果是这样,较短的域将用于后续的源检查。例如,假设文档中的脚本http://store.company.com/dir/other.html
执行以下语句:
document.domain = "company.com";
该语句执行后,页面将通过原始检查http://company.com/dir/page.html
。但是,出于同样的原因,company.com 无法设置document.domain
为othercompany.com
.
使用此方法,您将被允许从源自主域的页面上的子域上的 iframe 执行 javascript。此方法不适用于跨域资源,因为 Firefox 等浏览器不允许您将其更改document.domain
为完全陌生的域。
来源:https : //developer.mozilla.org/en/Same_origin_policy_for_JavaScript
跨域资源共享(CORS) 是 W3C 工作草案,它定义了跨域访问源时浏览器和服务器必须如何通信。CORS 背后的基本思想是使用自定义 HTTP 标头来允许浏览器和服务器充分了解彼此,以确定请求或响应是成功还是失败。
对于一个简单的请求,即使用GET
或POST
不使用自定义标头且主体为text/plain
的请求,将使用名为 的额外标头发送请求Origin
。Origin 标头包含请求页面的来源(协议、域名和端口),以便服务器可以轻松确定它是否应该提供响应。示例Origin
标题可能如下所示:
Origin: http://www.stackoverflow.com
如果服务器决定应该允许该请求,它会发送一个Access-Control-Allow-Origin
标头,回显发送的同一来源或者*
它是否是公共资源。例如:
Access-Control-Allow-Origin: http://www.stackoverflow.com
如果缺少此标头,或来源不匹配,则浏览器将拒绝该请求。如果一切顺利,浏览器就会处理请求。请注意,请求和响应都不包含 cookie 信息。
Mozilla 团队在他们关于 CORS 的帖子中建议您应该检查该withCredentials
属性是否存在,以确定浏览器是否通过 XHR 支持 CORS。然后你可以结合XDomainRequest
对象的存在来覆盖所有浏览器:
function createCORSRequest(method, url){
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr){
xhr.open(method, url, true);
} else if (typeof XDomainRequest != "undefined"){
xhr = new XDomainRequest();
xhr.open(method, url);
} else {
xhr = null;
}
return xhr;
}
var request = createCORSRequest("get", "http://www.stackoverflow.com/");
if (request){
request.onload = function() {
// ...
};
request.onreadystatechange = handler;
request.send();
}
请注意,要使 CORS 方法起作用,您需要有权访问任何类型的服务器标头机制,而不能简单地访问任何第三方资源。
来源:http : //www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-origin-resource-sharing/
window.postMessage
方法window.postMessage
, 当被调用时,导致MessageEvent
在任何必须执行的挂起脚本完成时在目标窗口分派a (例如,如果window.postMessage
从事件处理程序中调用剩余的事件处理程序,先前设置的挂起超时等)。的MessageEvent
具有类型消息,data
其被设置为提供到所述第一参数的字符串值属性window.postMessage
,一个origin
对应于窗口调用主文档的原点属性window.postMessage
在时间window.postMessage
被调用,并且一个source
属性,该属性是窗口从这window.postMessage
被称为。
要使用window.postMessage
,必须附加事件侦听器:
// Internet Explorer
window.attachEvent('onmessage',receiveMessage);
// Opera/Mozilla/Webkit
window.addEventListener("message", receiveMessage, false);
并且receiveMessage
必须声明一个函数:
function receiveMessage(event)
{
// do something with event.data;
}
场外 iframe 还必须通过postMessage
以下方式正确发送事件:
<script>window.parent.postMessage('foo','*')</script>
任何窗口都可以在任何其他窗口上访问此方法,无论文档在窗口中的位置如何,都可以随时向其发送消息。因此,任何用于接收消息的事件侦听器都必须首先使用来源和可能的来源属性检查消息发送者的身份。不能低估这一点:未能检查origin
和可能的source
属性会导致跨站点脚本攻击。
来源:https : //developer.mozilla.org/en/DOM/window.postMessage
在服务器上设置一个简单的反向代理,将允许浏览器使用 Ajax 请求的相对路径,而服务器将充当任何远程位置的代理。
如果在 Apache 中使用mod_proxy,则设置反向代理的基本配置指令是ProxyPass
. 它通常如下使用:
ProxyPass /ajax/ http://other-domain.com/ajax/
在这种情况下,浏览器将能够以/ajax/web_service.xml
相对 URL 的形式请求,但服务器将通过充当 的代理来提供服务http://other-domain.com/ajax/web_service.xml
。
此方法的一个有趣特性是反向代理可以轻松地将请求分发到多个后端,从而充当负载均衡器。
我使用 JSONP。
基本上,你添加
<script src="http://..../someData.js?callback=some_func"/>
在您的页面上。
some_func() 应该被调用,以便通知您数据在。
AnyOrigin没有一些https网站运行良好,所以我只是写一个开源替代whateverorigin.org,似乎以https很好地工作。
克服我发现的同源策略的最新方法是http://anyorigin.com/
该网站的制作使您只需给它任何 url,它就会为您生成 javascript/jquery 代码,让您可以获取 html/data,而不管它的来源。换句话说,它使任何 url 或网页成为 JSONP 请求。
我发现它非常有用:)
这是来自 anyorigin 的一些示例 javascript 代码:
$.getJSON('http://anyorigin.com/get?url=google.com&callback=?', function(data){
$('#output').html(data.contents);
});