Hacker News Reader

Comment by ricardobeat | Hacker News Reader

For hackers:

    window.onerror = function(m, f, l){
      var err = JSON.encode({ message:m, file:f, line:l })
      (new Image).src = '/errors?e='+err
    }

For Google Analytics users:

    window.onerror = function(m, f, l){
      var err = [f, l, m].join(' : ')
      _gaq.push(['_trackEvent', 'Errors', 'App', err, null, true])
    }

Analytics will allow you to filter by OS, browser, and all the other environment data it already captures. And nice graphs as a bonus :)

View on HN

Why wrap everything in json? Then you'll just have to decode it on the other end. Just use url parameters, it's what they are for:

    (new Image).src = '/errors?m='+encodeURIComponent(m)+
       '&f='+encodeURIComponent(f)+'&l='+encodeURIComponent(l);

This way it also works on browsers that don't have native JSON (old IE mainly, but also firefox before 3.5). And those are also exactly the browsers where you are likely to get errors since you are probably not testing using them.

Currently it's usually easier to decode JSON than to parse a query string. Modify to taste.

You don't need to encode the strings, the browser will do that for src.

> Currently it's usually easier to decode JSON than to parse a query string.

I don't see how that could be when you anyway have to parse the query string to get the e parameter. It costs nothing extra to get additional parameters.

> You don't need to encode the strings, the browser will do that for src.

Not in my testing - if the error message includes an & it will appear to the webserver as a new url parameter.

And actually that's a bug in your JSON version as well - you need to encode it before sending it.

Yes, I overlooked that. The way I'm doing that right now is with a route /errors/$message, so there's no query string parsing going on.

I also typed encode instead of stringify, and forgot to add a semi-colon after wrapping new Image in parentheses...

How do you keep a nefarious script kiddie from filling up your logs with bogus data? My thoughts were this:

1. Set the window.onerror to immediately push errors to an array 2. Load a small unique script that will create a basic sendError function to post the onerror arguments to an endpoint with a unique csrf set. 3. Loop through the arguments that are queued up and send them to the endpoint. 4. Replace the window.onerror with the sendError function.

Your endpoint can be an API that will log the data to either something like Graylog2 or whatever your favorite logging system is. Not 100% bullet proof but better then nothing.

> How do you keep a nefarious script kiddie from filling up your logs with bogus data?

You don't. Such a behavior is boring to them, so most won't. It does not provide money nor a way into the server, so no motivation.

If they want to DOS you they have many possible methods, adding this doesn't really change anything.

For some reason I thought they were doing more than this, like proxying your JavaScript (hence PROXino), instrumenting it with try/catches to provide robust stack traces, but apparently not: https://www.proxino.com/p.js

That's what the old version of Proxino did... but potential customers didn't like the proxy.

They load in jQuery? That isn't the true third-party javascript way...

Reply on news.ycombinator.com