Cryptic "Erreur de script". rapporté en Javascript dans Chrome et Firefox
J'ai un script qui détecte les erreurs Javascript sur mon site et les envoie à mon serveur pour les signaler. Il signale la première erreur rencontrée, le numéro de ligne supposé et l'heure.
EDIT pour inclure doctype:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:fb="http://www.facebook.com/2008/fbml">
...
<script type="text/javascript">
//<![CDATA[
// for debugging javascript!
(function(window){
window.onerror = function(msg, url, ln) {
//transform errors
if (typeof(msg) === 'object' && msg.srcElement && msg.target) {
if(msg.srcElement == '[object HTMLScriptElement]' && msg.target == '[object HTMLScriptElement]'){
msg = 'Error loading script';
}else{
msg = 'Event Error - target:' + msg.target + ' srcElement:' + msg.srcElement;
}
}
msg = msg.toString();
//ignore errors
if(msg.indexOf("Location.toString") > -1){
return;
}
if(msg.indexOf("Error loading script") > -1){
return;
}
//report errors
window.onerror = function(){};
(new Image()).src = "/jserror.php?msg=" + encodeURIComponent(msg) + "&url=" + encodeURIComponent(url || document.location.toString().replace(/#.*$/, "")) + "&ln=" + parseInt(ln || 0) + "&r=" + (+new Date());
};
})(window);
//]]>
</script>
À cause de ce script, je suis extrêmement conscient des erreurs javascript qui se produisent sur mon site. Un des plus gros délinquants est "Erreur de script." sur la ligne 0. dans Chrome 10+ et Firefox 3+. Cette erreur n'existe pas (ou peut être appelée autre chose?) Dans Internet Explorer.
Correction (5/23/2013): Cette erreur "Erreur de script, ligne 0" s'affiche maintenant dans IE7 et éventuellement dans d'autres versions d'IE. Peut-être un résultat d'un correctif de sécurité récent IE, car ce comportement n'existait pas auparavant.
Quelqu'un a-t-il une idée de ce que cette erreur signifie ou de sa cause? Cela se produit sur environ 0,25% de mes pageloads globaux et représente la moitié des erreurs signalées.
Le "erreur de script." se produit dans Firefox, Safari et Chrome lorsqu'une exception enfreint la règle same-Origin du navigateur - c'est-à-dire lorsque l'erreur se produit dans un script hébergé sur un domaine autre que celui de la page en cours.
Ce comportement est intentionnel afin d'empêcher les scripts de divulguer des informations vers des domaines externes. Pour un exemple de la raison pour laquelle cela est nécessaire, imaginez que vous visitiez par inadvertance evilsite.com, qui affiche une page avec <script src="yourbank.com/index.html">. (oui, nous pointons cette balise de script vers html, pas JS). Cela entraînera une erreur de script, mais l'erreur est intéressante car elle peut nous dire si vous êtes connecté ou non. Si vous êtes connecté, l'erreur peut être 'Welcome Fred...' is undefined, alors que si vous ne l'êtes pas, il pourrait s'agir de 'Please Login ...' is undefined. Quelque chose dans ce sens.
Si evilsite.com le fait pour les 20 institutions bancaires les plus importantes, elles auront une assez bonne idée des sites bancaires que vous visitez et pourraient fournir une page de phishing beaucoup plus ciblée. (Ce n'est qu'un exemple, bien sûr. Mais cela illustre pourquoi les navigateurs ne devraient pas autoriser aucune donnée à traverser les limites de domaine.)
J'ai testé cela dans les dernières versions de Safari, Chrome et Firefox - ils le font tous. IE9 ne le fait pas - il traite les exceptions x-Origin de la même manière que les exceptions identiques. (Et Opera ne supporte pas onerror.)
Depuis la bouche du cheval: Source WebKit qui vérifie l’origine lors du passage des exceptions à onerror (). Et le source de Firefox qui vérifie .
UPDATE (10/21/11): Le bogue de Firefox qui suit ce problème inclut un lien vers la publication de blog qui a inspiré ce comportement.
UPDATE (12/2/14): vous pouvez désormais activer le rapport d'erreurs inter-domaines complet sur certains navigateurs en spécifiant un attribut crossorigin sur les balises de script et en demandant au serveur d'envoyer les CORS En-têtes de réponse HTTP.
Une mise à jour pour ceux qui trébucheront sur cette question à l'avenir: Broofa a raison avec la réponse et il n'y a pas de solution de contournement pour cela.
Évidemment, d'autres limitations sont apparues et des bogues demandant une correction ont été répertoriés pour Firefox: Bug 69301 et pour WebKit: Bug 70574
La bonne nouvelle est que le bogue a été résolu pour Firefox avec la publication de Firefox 13 . Voici comment vous l'utilisez:
<script src="http://somremotesite.example/script.js" crossorigin>
crossorigin est équivalent à crossorigin=anonymous et demande au navigateur de effectuer une extraction CORS du script sans envoyer les informations d'identification.
Vous devez vous assurer que le script est envoyé avec une valeur d'en-tête HTTP Access-Control-Allow-Origin qui correspond au domaine demandeur, par exemple,
Access-Control-Allow-Origin: http://myhomesite.example
Access-Control-Allow-Origin: *
sinon le navigateur annulera le chargement du script.
Pour Apache:
Header set Access-Control-Allow-Origin "*"
(Et voir les exemples CORS pour autres serveurs Web .)
Si vous envoyez des scripts en PHP:
header('Access-Control-Allow-Origin', 'http://myhomesite.example');
J'ai testé cela et cela fonctionne comme prévu. toutes les erreurs de script.js seront interceptées par le gestionnaire window.onerror avec les détails du message, du fichier et de la ligne.
Le bogue WebKit n'a pas encore été corrigé, mais un correctif a été proposé (et utilise la même solution). Espérons que le correctif sera publié bientôt.
Plus d'infos sur CORS ici: http://enable-cors.org/
Celui-ci a pris un peu de temps à comprendre.
Nous avons fait beaucoup de choses pour essayer de résoudre ce problème, notamment en vendant le corps du document ENTIER à nos serveurs via Ajax pour essayer de le résoudre.
Je ne sais toujours pas ce qui cause "l'erreur de script". (avec la période BTW, c'est comme ça que ça se voit dans notre logger Ajax) dans Firefox, mais dans Chrome, nous avons pu le réduire à ...
Roulement de tambour...
La fonctionnalité de traduction automatique de Google Chrome.
Beaucoup de personnes parlant anglais ne connaissent probablement pas cette fonctionnalité, mais pour la tester, visitez un site non anglais à l'aide de Chrome. Ou mieux encore, si vous naviguez dans les options de Chrome, vous pouvez changer la langue du navigateur. Remplacez-le par une version non anglaise, redémarrez le navigateur et visitez un site en anglais.
La barre en haut vous demande si vous souhaitez que Chrome traduise la page pour vous.
De toute façon, dans notre cas, le traducteur était à l'origine du problème car il insérait une balise de script dans le corps de votre document et (devinons ici) utilisait une sorte de système basé sur JS pour envoyer le contenu aux serveurs de Google et les faire traduire.
Même si l'erreur dans la console était un élément non référencé, le message envoyé à window.onerror était "Erreur de script".
Quoi qu'il en soit, il existe un remède.
http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html
<meta name="google" content="notranslate"/>
Cela fera 2 choses (à notre connaissance, peut-être plus?):
a) Désactivez l'affichage de la barre de traduction dans Chrome.
b) Désactivez la traduction de la page via translate.google.com.
Dans notre cas de toute façon, ceci résout une tonne de ces "erreurs de script". problèmes que nous rencontrions.
Excusez les fautes d’orthographe de cet article, je suis toujours en mode non anglais dans Chrome, et le correcteur orthographique n’est pas défini en anglais;) Il est temps de revenir en arrière.
Prendre plaisir!
En raison du faible pourcentage, vous pouvez supposer qu'ils ne sont pas des utilisateurs normaux. Probablement les utilisateurs avec des scripts utilisateurs, des bookmarklets ou même peut-être simplement jouer avec la console de votre site Web… .. Avoir le code HTML complet d'une page sur laquelle cela se produit pourrait aider à tester cette théorie. Ainsi que l'erreur complète. Il devrait vous donner une URL, est-ce toujours la même chose? La ligne est-elle vraiment 0 ou juste indéfinie?
Je ne pense pas que définir des valeurs par défaut dans votre onerror soit une bonne idée et le 0 vient probablement de parseInt(ln || 0) lorsque l'erreur n'est pas vraiment sur la page (voir les exemples ci-dessus).
Ajouter un if pour voir si la ligne est connue soit dans le JavaScript pour ignorer ces erreurs (car elles ne proviennent probablement pas de votre propre code), soit dans le code côté serveur pour en prendre soin séparément, imo, be better .
=== EDIT === Accédez à: http://www.xavierm02.net/AZE/ Installez le fichier user.js (je l’ai fait sous Chrome, mais il devrait travaillez également sur Firefox) . Ouvrez ensuite la page html du même navigateur. Cela va vous montrer l'erreur (j'ai seulement changé cette insteal de rapporter au serveur, ça l'écrit sur la page). Avec 0 comme numéro de ligne.
J'ai eu un problème similaire: mes scripts sont servis par un sous-domaine et relèvent de la même restriction d'origine. Cependant, j'ai résolu ceci en:
1) ajouter chaque balise de script comme ceci:
<script type="text/javascript" src="http://subdomain.mydomain.tld" crossorigin="*.mydomain.tld" />
2) en modifiant Apache httpd.conf en ajoutant ce qui suit dans chaque hôte (vous devez enbable mod_headers):
<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*.mydomain.tld"
</IfModule>
J'espère que cela t'aides ...
MODIFIER
Sur un de mes serveurs, je n’ai pas pu le rendre fonctionnel sauf en remplaçant
*.mydomain.tld
par
*
Soyez conscient des failles avec potentiellement permettre * de phishing informations étendues. La documentation sur CORS, same-Origin, img & fonts, cdn est disponible, mais beaucoup moins de détails sur les balises de script sont disponibles.
Que diriez-vous du dessous. L'erreur de script n'étant pas disponible via JavaScript, il vous suffit d'isoler ce cas particulier et de le gérer au mieux.
window.onerror = function (msg, url, lineNo, columnNo, error) {
var string = msg.toLowerCase();
var substring = "script error";
if (string.indexOf(substring) > -1){
alert('Script Error: See Browser Console for Detail');
} else {
alert(msg, url, lineNo, columnNo, error);
}
return false;
};
Dans Chrome, le message d'erreur "Erreur de script" (ligne 0) apparaît également lors du chargement du code HTML et du code JavaScript à partir de file://. Cela n'arrive pas dans Firefox. Protection de Chrome de même origine probablement trop zélée.
Tout va bien lorsque vous chargez le même code HTML et Javascript via HTTP.
Un bon article qui pointe finalement vers ce fil. https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/
Je vais vous dire ce qui m’a corrigé pour moi sur Safari (WebKit): Si je mets réellement la routine de rappel JS sur la page , alors j’obtiens des informations complètes. Si je l'inclue dans un fichier .js via une balise, j'obtiens simplement l'erreur "Erreur de script" (sans numéro de taille, etc.).
Peut-être que cela est lié à ce que Broofa a dit.
Quoi qu'il en soit, j'ai maintenant un petit rappel dans la page, puis le reste du fichier en dehors de la page.