Registrazione degli errori JavaScript sul lato client sul server [chiuso]

97

Sto eseguendo un sito ASP.NET in cui ho problemi a trovare alcuni errori JavaScript solo con i test manuali.

C'è la possibilità di rilevare tutti gli errori JavaScript sul lato client e registrarli sul server, ad esempio nel registro eventi (tramite il servizio Web o qualcosa del genere)?

javascript logging error-handling

— MADMap
fonte

Il problema per cui non stiamo utilizzando JavaScript UnitTesting è perché ci sono troppe persone che contribuiscono al sito / contenuto e utilizzano JavaScript. Il contenuto non è nulla di cui (come sviluppatori) dovremmo preoccuparci, ma ci sono errori nel codice. Quindi una soluzione generale sarebbe migliore.

— MADMap

Presumo che tu non intenda il contributo di un utente medio (altrimenti è un buco XSS) ... ma ... potresti forse isolare il loro JS in try / catch in modo che almeno non influenzi il tuo JS ... senza saperlo la dinamica del sito, non so se questo aiuterà o no ...

— Mike Stone

Il contenuto proviene da altri team dell'azienda, non dagli utenti, quindi non è un rischio per la sicurezza

— MADMap

Bugsnag registrerà automaticamente i tuoi errori e li mostrerà in una dashboard. Funziona per .NET e JS.

— Don P

68

Potresti provare a configurare il tuo gestore per l' evento onerror e usare XMLHttpRequest per dire al server cosa è andato storto, tuttavia poiché non fa parte di alcuna specifica, il supporto è alquanto instabile .

Ecco un esempio tratto dall'utilizzo di XMLHttpRequest per registrare gli errori JavaScript :

window.onerror = function(msg, url, line)
{
  var req = new XMLHttpRequest();
  var params = "msg=" + encodeURIComponent(msg) + '&amp;url=' + encodeURIComponent(url) + "&amp;line=" + line;
  req.open("POST", "/scripts/logerror.php");
  req.send(params);
};

— Jonny Buchanan
fonte

Ho appena rilasciato un controllo server che ti aiuta a farlo su thecodepage.com/post/JavaScript-Error-Notifications.aspx

— Gabriel McAdams

2

Andrà in loop all'infinito se si blocca nel gestore?

— Jean-Philippe Leclerc

2

@ Jean-PhilippeLeclerc Sì. E peggio ancora, eseguirà il DoS sull'endpoint del tuo server se dovessi cadere in un ciclo di errori. Dovresti aggiungere una funzione di limitazione a questo per impedire a un client di raggiungere il server troppo velocemente. Ecco un esempio di questo da {Track: js} github.com/TrackJs/Tech-Demo/blob/master/src/TrackJs.Demo/…

— Todd Gardner

Puoi anche crittografare un token che include l'ID dell'utente, l'IP, una piccola stringa casuale (per sventare gli attacchi con testo in chiaro se il tuo algoritmo di crittografia è veloce ma debole) e un timestamp e includerlo come variabile JS nella pagina. Questo può quindi essere inviato con il rapporto di errore e controllato prima di consentirne l'aggiunta ai log. Questo aiuta a dimostrare la probabile autenticità del messaggio di errore e protegge da stupidi attacchi DoS, ma non ti proteggerà da tentativi DoS più sofisticati come lo farà il throttling.

— mormegil

Questa cosa può sopraffare il tuo server, ad esempio se ottieni un errore nel setIntervalmetodo. Esistono molti servizi di segnalazione degli errori JS disponibili sul Web. Checkout ErrLytics . Ti offre anche analisi di ogni azione dell'utente sul tuo sito web.

— Vivek Marakana

28

Risposta breve: Sì, è possibile.

Risposta più lunga: le persone hanno già scritto su come è possibile (almeno parzialmente) risolvere questo problema scrivendo il proprio codice. Tuttavia, tieni presente che ci sono servizi là fuori che sembrano aver fatto in modo che il codice JS necessario funzionasse in molti browser. Ho trovato quanto segue:

Non posso parlare per nessuno di questi servizi perché non li ho ancora provati.

— Ztyx
fonte

1

Registrato con muscula.com. Il servizio sembra molto interessante e facile da integrare e utilizzare. Esiste anche la libreria JavaScript github.com/csnover/TraceKit che consente di ottenere informazioni sull'eccezione dal client, ma è necessario sviluppare il proprio meccanismo di accesso lato server. Mi chiedo se Google Analytics possa essere utilizzato per questo

— Maksym Kozlenko

1

trackjs.com e tiene traccia di ciò che l'utente e la rete stavano facendo prima dell'errore.

— Todd Gardner

Oltre alla lista qui sopra c'è anche, log4sure.com è gratuito e ha anche il monitoraggio in tempo reale dei log. Puoi anche creare la tua tabella di registro personalizzata

— Bhavin

erroralerts.com non trovato

— Kiquenet

1

jsnlog.com è gratuito e open source .

— stomy

12

Ho appena implementato la registrazione degli errori lato server sugli errori javascript su un progetto al lavoro. Esiste una combinazione di codice legacy e nuovo codice che utilizza jQuery .

Uso una combinazione di window.onerrore avvolgendo i gestori di eventi jQuery e la funzione onready con una funzione di gestione degli errori (vedi: Monitoraggio degli errori JavaScript: Perché window.onerror non è sufficiente ).

window.onerror: rileva tutti gli errori in IE (e la maggior parte degli errori in Firefox), ma non fa nulla in Safari e Opera.
Gestori di eventi jQuery: rileva gli errori di eventi jQuery in tutti i browser.
Funzione jQuery ready: rileva gli errori di inizializzazione in tutti i browser.

Una volta rilevato l'errore, aggiungo alcune proprietà extra (URL, browser, ecc.) E poi lo invio nuovamente al server utilizzando una chiamata ajax.

Sul server ho una piccola pagina che prende solo gli argomenti pubblicati e li invia al nostro normale framework di registrazione del server.

Vorrei rendere open source il codice per questo (come plugin jQuery). Se qualcuno è interessato fammelo sapere, aiuterebbe a convincere i capi!

— Karl
fonte

1

C'è qualche possibilità che questo codice venga reso disponibile?

— Luca

Purtroppo no :( dato che non lavoro più per la società in cui ho creato quel codice. Ma erano solo circa 100 righe di codice e dovrebbe essere ragionevolmente facile da ricreare dai dettagli sopra.

— Karl

1

è proprio qui ragazzi: webcache.googleusercontent.com/…

— Devin G Rhode

L'ho provato, ma mantenere jquery nella dipendenza è una seccatura e window.onerror fa schifo per il codice minimizzato e javascript che viene servito tramite cdns

— Ankur Agarwal

2

Se utilizzi Google Analytics, puoi registrare gli errori javascript negli eventi di Google Analytics.

Vedi questa app: http://siteapps.com/app/log_javascript_errors_with_ga-181

Spero che sia d'aiuto.

— Leandro Lages
fonte

2

Quel collegamento non funziona più. Puoi trovare un articolo sulla registrazione degli errori Javascript con Google Analytics su developers.google.com/analytics/devguides/collection/…

— Martin Omander,

0

Raccomando anche di utilizzare l' utilità TraceTool , viene fornito con il supporto JavaScript ed è molto utile per il monitoraggio JS.

— cleg
fonte

TraceTool è morto?

— Kiquenet

0

Se desideri registrare gli errori lato client sul server, dovrai eseguire una sorta di elaborazione del server. La cosa migliore sarebbe avere un servizio web a cui puoi accedere tramite JavaScript (AJAX) e passargli le informazioni del registro degli errori.

Non risolve il problema al 100% perché se il problema è con il server web che ospita il servizio web sei nei guai, l'altra opzione sarebbe inviare le informazioni tramite una pagina standard tramite una stringa di query, un metodo di ciò avviene tramite la generazione dinamica di tag immagine (che vengono quindi rimossi) poiché il browser proverà a caricare l'origine di un'immagine. Tuttavia, aggira bene le chiamate JavaScript interdominio. Tieni presente che sei nei guai se qualcuno ha le immagini disattivate;)

— Aaron Powell
fonte

0

Recentemente ho utilizzato Appfail , che cattura sia gli errori asp.net che JavaScript

— levelnis
fonte

0

Potresti potenzialmente effettuare una chiamata Ajax al server da una prova / cattura, ma probabilmente è il meglio che puoi fare.

Posso suggerire invece un test di unità JavaScript? Possibilmente con JSUnit ?

— Mike Stone
fonte

Il problema per cui non stiamo usando JavaScript UnitTesting è perché ci sono troppe persone che contribuiscono al sito / contenuto e usano JavaScript (ma non ne hanno la più pallida idea!) Quindi una soluzione generale sarebbe migliore.

— MADMap