Logging Javascript errors in production

We had implemented a javascript logger to capture the pesky issues our users faced and had problems with when using the site. When we came up with the idea, we thought it would be just a five-minute job where we would just have to add a snippet and would be done, but nothing is simple when it comes to real-world production issues, it it?

After analyzing a lot of loggers, we decided to use errorception as our javascript logger. It was simple in its approach, and it provided the data we needed. This was the easy part, next came integration, and yes there was a snippet which we just had to paste in our base javascript file. There was one thing we had forgotten, CORS!

We host our static files on S3, and they are served via Fastly because of which they are delivered through another domain. The error tracking snippet could not log the errors because "window.onerror" would not return the necessary stack trace and information.

Many of you may have heard about CORS; it is a mechanism that allows restricted resources (e.g. fonts) on a webpage to be requested from a domain outside the one it originated from. For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. The only way to solve this and get errors posted to errorception was to allow CORS in the header of the static files.

After some research (errorception also has a good blog on it), we finally managed to get the error logging implemented. Following are the steps:

Configuring S3

S3 has this unnecessarily complicated "CORS configuration" that you need to create. Here are the steps to get it right:

  • Log into your AWS S3 console, select your bucket, and select "Properties." S3 CORS configurations seem to apply at the level of the bucket and not the file. I have no clue why.
  • Expand the "Permissions" pane, and click "Add CORS configuration" or "Edit CORS configuration" depending on what you see.
  • You should already be provided with a default permission configuration XML. If not, use the following XML to get started.

You should look at Amazon's docs to see what this configuration means.

  • Make sure you add <?xml ?> declaration; if you omit these, Amazon will fail silently, showing you a happy- looking green tick!
  • Once you've saved the configuration, give it a couple of minutes.
  • Test if everything's looking right. You could use a tool like curl to specify the additional headers needed for a "correct" CORS request:

You should see the "Access-Control-Allow-Origin:*" header, and the "Vary: Origin" header in the output. If you do, you're golden.

Configuring Fastly

For configuring fastly, we just had to follow a few simple steps and then we were done:

  • Set up a custom HTTP header via the Content pane for your service.
  • Then, create a custom header with the following information that adds the required "Access-Control-Allow-Origin" header for all requests.
  • Finally, test it out: Running the command curl -I your-hostname.com/path/to/resource should include similar information for the following in your header:

Once we had the "Access-Control-Allow-Origin" set up for both S3 and Fastly, we had one major thing left to do— to add crossorigin=’anonymous’ to all our script tags. For this, we used a simple regex to modify the existing script tags in all the files:

After this we just bumped the version of all js files (to clear cache), then we were done. We finally had the js logger implemented.

This helped us identify the javascript issues in real-time and make the user experience better across all browsers.

And as always, Happy Coding!


Send an email to support@hackerearth.com for any bugs or suggestions.

This post was originally written for the HackerEarth Engineering blog by Shivindera Singh.

About the Author

Guest Author
Our guest articles are a collection of the best contributions made by members of the developer community on our blog. Discover articles on a wide range of topics, shared by top programmers across the world.