Come vedere cosa viene restituito quando uno script remoto è bloccato

Question

Sto usando jQuery in hosting su Google nella mia webapp (//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js) Come parte della diagnostica dei bug ho un gestore window.onerror che cattura eventuali errori che non sto rilevando localmente e consente al server di conoscerli.

Fin qui tutto bene, ma ... a volte ho errori come questi:

"Errore di script", "Errore durante il caricamento di script", "Unexpected gettone <"

mio l'ipotesi è che il CDN di Google sia bloccato in questi casi (per qualsiasi motivo). Ho un fallback locale per jQuery, che sono abbastanza sicuro sta funzionando bene, ma mi piacerebbe scoprire cosa viene restituito in modo da poter testare le mie ipotesi e forse ottenere alcuni di questi utenti su una lista bianca per Google CDN (se è il firewall aziendale che lo blocca).

Ma finora non sono stato in grado di capire come recuperare il contenuto restituito. Impossibile recuperare innerText di un tag SCRIPT se si tratta di un file, non è possibile effettuare una richiesta Ajax a causa di criteri interdominio, ecc.

Qualcuno ha qualche idea su come ciò sarebbe possibile?

Answer 1

Semplicemente non è possibile ottenere il contenuto di qualsiasi file referenziato da un tag <script>. Questo è un buon motivo: farlo in questo modo ti permetterebbe di eludere la stessa politica sull'origine di XHR.

considerare:

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

Se si potesse accedere al testo della respnse, saresti in grado di fare questo:

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

Questo è ovviamente male. Pertanto, non ti è mai consentito leggere il contenuto di qualcosa introdotto dai tag <script>.

tua particolare situazione è complicata da una recente introduzione relativamente change in cui errori di script cross-origine non riportano informazioni qualsiasi utili per onerror gestore della tua pagina. (Essenzialmente, questo è stato fatto per rattoppare un buco di sicurezza di divulgazione delle informazioni che consente ad un sito malevolo di dedurre se hai effettuato l'accesso ad alcuni siti noti, tra le altre cose.)

Ciò significa che non si ottengono informazioni utili sugli errori dallo script ospitato da CDN, quindi è stato creato another change per consentire l'utilizzo di un server CDN (o altro non di origine diversa) da utilizzare per consentire a dettagli completi di errore di passare a un gestore onerror.

Noi (Facebook) abbiamo bisogno di un meccanismo per disabilitare il comportamento di muting window.onerror implementato in #363897. Le nostre risorse di script statici sono servite su un CDN in un dominio diverso dal sito principale. Poiché questi domini differiscono, stiamo cadendo in conflitto con la logica del dominio x che ci impedisce di raccogliere informazioni utili sugli errori del browser.

Questa "funzione" è stata ampiamente adottata in natura (nei browser Firefox e Webkit) che la maggior parte delle eccezioni non rilevate che vediamo nella produzione ora non contengono informazioni utilizzabili.

Il crossorigin attribute (originariamente previsto per <img>) consente di specificare che una risorsa deve essere caricato con le regole CORS. È stato implementato da Mozilla, WebKit e Chrome.

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

Purtroppo per voi, nella mia testing, ho scoperto che il Google CDN non non inviare le intestazioni CORS.

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 

... 

nota la presenza del Origin nella richiesta (indicativo di una richiesta CORS), e l'assenza di un Access-Control-Allow-Origin intestazione nella risposta. Pertanto, anche se si inserisce l'attributo crossorigin, il controllo CORS non avrà esito positivo e gli script riceveranno i dettagli degli errori corretti.

C'è un three-year-old issue per abilitare CORS sul server CDN di Google. Non trattenerei il respiro.

---

TLDR: Se si desidera che i messaggi di errore significativi, è necessario ospitare tutte JavaScript te stesso, sulla stessa origine.