Es ist einfach nicht möglich, den Inhalt einer Datei zu erhalten, die von einem <script>-Tag referenziert wird. Dies hat einen guten Grund: Wenn Sie dies tun, können Sie die XHM-Richtlinien für gleiche Herkunft umgehen.
Bedenken Sie:
<script src="https://www.example.com/private/api/getAuthToken" id="s"></script>
Wenn Sie den Text des respnse zugreifen können, Sie in der Lage sein würde, dies zu tun:
var stolenAuthToken = $('#s').text();
die offensichtlich schlecht ist. Daher dürfen Sie nie den Inhalt von etwas lesen, das von <script> Tags eingebracht wurde.
Ihre besondere Situation ist change durch eine vor relativ kurzer Zeit eingeführt kompliziert, wo Fehler in Cross-Origin-Skripte berichten nicht jede nützliche Informationen zu Ihrem onerror Handler Seite. (Im Wesentlichen wurde dies getan, um eine Sicherheitslücke für die Offenlegung von Informationen zu schließen, die es einer bösartigen Website ermöglicht, unter anderem zu ermitteln, ob Sie bei einigen bekannten Websites angemeldet sind.)
Dies bedeutet, dass Sie keine nützlichen Informationen erhalten über Fehler von CDN-gehostetem Skript, so wurde another change gemacht, um die Verwendung von CORS für einen CDN (oder einen anderen nicht-ursprünglichen Ursprung) -Server zu ermöglichen, um die vollständigen Fehlerdetails an einen onerror-Handler übergeben zu können.
Wir (Facebook) benötigen einen Mechanismus zum Sperren des window.onerror Muting in #363897 umgesetzt Verhalten. Unsere statischen Skriptressourcen werden auf einem CDN unter einer anderen Domäne als der Haupt-Site bereitgestellt. Da diese Domänen unterschiedlich sind, sind wir der x-Domänen-Logik nicht mehr gewachsen, die uns daran hindert, nützliche Informationen über Browserfehler zu sammeln.
Dieses "Feature" wurde in der freien Natur (in Firefox- und Webkit-Browsern) weit genug angenommen, dass die Mehrheit der nicht abgefangenen Ausnahmen, die wir in der Produktion sehen, keine verwertbaren Informationen mehr enthält.
Die crossorigin attribute (ursprünglich für <img> bestimmt) ermöglicht es Ihnen, dass eine Ressource angeben soll mit CORS Regeln geladen werden. Es wurde von Mozilla, WebKit und Chrome implementiert.
<script src="http://example.com/xdomainrequest" crossorigin="anonymous"></script>
Leider für Sie, in meinem testing, fand ich, dass die Google CDN tut nicht CORS-Header senden.
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
...
Notiere die Anwesenheit des Origin Header in der Anforderung (was eine CORS Anfrage), und das Fehlen eines Access-Control-Allow-Origin Header in der Antwort. Selbst wenn Sie das Attribut crossorigin setzen, schlägt die CORS-Prüfung fehl, und Ihre Skripts erhalten bereinigte Fehlerdetails.
Es gibt eine three-year-old issue, um CORS auf dem Google CDN-Server zu aktivieren. Ich würde meinen Atem nicht anhalten.
TLDR: Wenn Sie aussagekräftige Fehlermeldungen wollen, müssen Sie alle JavaScript selbst hosten, auf dem gleichen Ursprung.
irgendwie was ich dachte. Ich werde sehen, ob ich direkt mit betroffenen Benutzern nachforschen kann. Vielen Dank. – Pyro979
So detailliert, ausgezeichnete Post! – potench