怎么看时,远程脚本被阻止返回什么 [英] How to see what is returned when a remote script is blocked

查看:177
本文介绍了怎么看时,远程脚本被阻止返回什么的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用谷歌托管的jQuery在我的web应用程序(//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js)由于错误诊断的一部分,我有一个window.onerror处理程序这抓住我没有在本地捕获的任何错误,并让服务器知道它们。

I'm using Google hosted jQuery in my webapp (//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js) As part of bug diagnostics I have a window.onerror handler which catches any errors I'm not catching locally and lets the server know about them.

到目前为止好,但是......有时我喜欢这些错误:

So far so good, but... sometimes i get errors like these:

脚本错误,错误加载脚本,意外令牌LT;

"Script error.","Error loading script","Unexpected token <"

我的假设是,谷歌CDN被挡在这些情况下(无论何种原因)。我也有jQuery的本地回退,那我相当肯定是工作好,但我想找出的返回什么,这样我可以测试我的假​​设和可能得到一些用户的白名单的谷歌CDN上(如果是公司防火墙阻止它)。

My assumption is that the Google CDN is blocked in these cases (for whatever reason). I do have a local fallback for jQuery, that I'm fairly sure is working well, but I would like to find out what's being returned so that I can test my assumptions and maybe get some of these users on a white list for Google CDN (if it's company firewall blocking it).

但到目前为止,我一直无法弄清楚如何检索返回的内容。无法检索的innerText脚本标签如果它是一个文件,不能做,因为跨域策略等Ajax请求

But so far I haven't been able to figure out how to retrieve the returned content. Can't retrieve innerText of a SCRIPT tag if it's a file, can't do an ajax request because of cross-domain policy, etc.

有没有人有关于如何这是有可能的任何想法?

Does anyone have any ideas about how this would be possible?

推荐答案

这根本是不可能得到所引用的任何文件的内容&LT;脚本&GT; 标签。这是有充分的理由:这样做会允许你绕过XHR的同源策略

It simply isn't possible to get the content of any file referenced by a <script> tag. This is with good reason: doing so would allow you to circumvent XHR's Same Origin Policy.

考虑:

<script src="https://www.example.com/private/api/getAuthToken" id="s"></script>

如果你能访问respnse的文字,你能做到这一点:

If you could access the text of the respnse, you'd be able to do this:

var stolenAuthToken = $('#s').text();

这显然不好。因此,你永远不许通过阅读带来的东西的内容&LT;脚本方式&gt; 标签

您的具体情况由相对最近推出的在改变错误的地方跨域脚本不报告的任何的有用的信息到你的页面的的onerror 处理程序。 (本质上来说,这样做是为了修补一个信息披露的安全漏洞,允许恶意站点来推断是否已经登录一些知名网站,除其他事项外)。

Your particular situation is complicated by a relatively recently introduced change where errors in cross-origin scripts do not report any useful information to your page's onerror handler. (Essentially, this was done to patch an information disclosure security hole that allows a malicious site to infer whether you're logged in to some well-known sites, among other things.)

这意味着你获取有关CDN承载的脚本错误没有任何有用的信息,所以另一变化有人以允许使用 CORS的 CDN(或其他非同源)服务器来选择允许全部错误详情要传递给的onerror 处理程序。

This means that you get no useful information about errors from CDN-hosted script, so another change was made to allow the use of CORS for a CDN (or other non-same-origin) server to opt in to allowing full error details to pass to an onerror handler.

我们(脸谱)需要在禁用的 window.onerror 静音行为的机制。 CGI?ID = 363897相对=nofollow>#363897 。我们的静态脚本资源在从主站点不同的域送达CDN。由于这些不同的领域我们触犯了下跌$ P $从收集有关浏览器错误的有用信息pvents我们的X域逻辑的。

We (Facebook) need a mechanism for disabling the window.onerror muting behavior implemented in #363897. Our static script resources are served on a CDN under a different domain from the main site. Because these domains differ we're falling afoul of the x-domain logic that prevents us from gathering useful information about browser errors.

这个功能已经足够宽在野外通过的(在Firefox和WebKit浏览器),大多数我们看到生产未捕获异常的,现在在他们没有可操作的信息。

This "feature" has been widely enough adopted in in the wild (in Firefox and Webkit browsers) that the majority of uncaught exceptions we see in production now have no actionable information in them.

crossorigin 属性(原本是为&LT; IMG&GT; )允许您指定的资源应与CORS规则被加载。它已被由Mozilla,的WebKit 和的 Chrome浏览器

The crossorigin attribute (originally intended for <img>) allows you to specify that a resource should be loaded with CORS rules. It has been implemented by Mozilla, WebKit, and Chrome.

<script src="http://example.com/xdomainrequest" crossorigin="anonymous"></script>

不幸的是你,在我的测试,我发现谷歌确实CDN的发送CORS标头。

Unfortunately for you, in my testing, I found that the Google CDN does not send CORS headers.

GET http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js HTTP/1.1
Host: ajax.googleapis.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://fiddle.jshell.net/josh3736/jm2JU/show/
Origin: http://fiddle.jshell.net
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Type: text/javascript; charset=UTF-8
Last-Modified: Tue, 13 Nov 2012 19:53:02 GMT
Date: Wed, 02 Jan 2013 22:54:25 GMT
Expires: Thu, 02 Jan 2014 22:54:25 GMT
X-Content-Type-Options: nosniff
Server: sffe
Content-Length: 93637
X-XSS-Protection: 1; mode=block
Cache-Control: public, max-age=31536000
Age: 169036

...

请注意在请求中的原产地头的presence(表示CORS要求),而且没有一个访问控制的 - 允许原产地头中的响应。因此,即使你把 crossorigin 属性中,CORS检查会失败,你的脚本将收到擦洗错误的详细信息。

Note the presence of the Origin header in the request (indicating a CORS request), and the absence of an Access-Control-Allow-Origin header in the response. Thus, even if you put the crossorigin attribute, the CORS check will fail, and your scripts will receive scrubbed error details.

有一个三年 - 老问题使谷歌CDN服务器上CORS。我不认为我的呼吸。

There is a three-year-old issue to enable CORS on the Google CDN server. I wouldn't hold my breath.

tldr:如果您想有意义的错误消息,您必须承载所有的JavaScript自己,对同一产地

tldr: If you want meaningful error messages, you must host all JavaScript yourself, on the same origin.

这篇关于怎么看时,远程脚本被阻止返回什么的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆