Skip to content

Custom exceptions throw globally aren't filtered by whitelistUrls #503

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bradvogel opened this issue Feb 10, 2016 · 10 comments · Fixed by #582
Closed

Custom exceptions throw globally aren't filtered by whitelistUrls #503

bradvogel opened this issue Feb 10, 2016 · 10 comments · Fixed by #582

Comments

@bradvogel
Copy link

When some third party code throws a non-Error object, it's being collected by Raven's window.onerror handler and being fowarded to captureMessage, which doesn't use whitelistUrls to filter exceptions.

I'd expect that ALL global exceptions (that get caught by window.onerror) are passed through whitelistUrls, regardless of their type.

Code to reproduce:

  // Set up Raven:
  Raven.config('...', {
    whitelistUrls: [/myfile\.js/],
  });

  // Install window.onerror handler.
  Raven.install();

  setTimeout(function(){
     throw new Error('this will get filtered out by whitelistUrls since this isn\'t being thrown from that file');
  });

  CustomError = function(message) {
    this.message = message;
  };

  setTimeout(function(){
     throw new CustomError('this will make it through!');
  });

This is an issue if you're including third party libraries on the page that might throw their own custom error object, and not catch it.

@bradvogel bradvogel changed the title Throwing custom exceptions aren't filtered by whitelistUrls Custom exceptions throw globally aren't filtered by whitelistUrls Feb 10, 2016
@wearhere
Copy link

+1

@benvinegar
Copy link
Contributor

@bradvogel – Your custom error needs to inherit from the Error prototype, e.g.

function CustomError = function(message) {
    this.message = message;
};
CustomError.prototype = Error.prototype;

Otherwise Raven does not consider this an error – it only knows that it is a function object, and cannot make any assertions about its properties. For example, your custom error will not have a stack property, even if it is thrown via the throw keyword.

@benvinegar
Copy link
Contributor

Oh, I think I've misread. Your example was meant to (intentionally) demonstrate a non-error that passes through to captureMessage, where it is not filtered. Right?

@benvinegar
Copy link
Contributor

In which case, I'm not sure what we can do. We extract the URL from an Error object's properties. A message / freeform object has no such property, so Raven.js does not know from which file the message originated from.

@bradvogel
Copy link
Author

Hi Ben :). The throw object is actually out of our control. It's throw by third party code running on the page. So if badfile.js is throwing CustomError, it's automatically getting forwarded to Sentry, regardless of us using whitelistUrls to try to filter out all errors from badfile.js.

My thought is that the window.onerror handler should filter all incoming exceptions through whitelistUrls before determining if they're a proper Error object. Right now it gets passed to captureMessage which is exempt from the whitelistUrls filter.

@benvinegar
Copy link
Contributor

Right. In your example though, onerror isn't catching the error – Raven wraps setTimeout with try/catch and likely catches it there (never reaching onerror). We do this because some browsers' onerror implementations do not provide stack traces (Safari, Edge, some versions of IE).

@bradvogel
Copy link
Author

Ok I see. But the bug makes sense - right? I just need a way to suppress all errors from third party scripts from making it into Sentry.

@bradvogel
Copy link
Author

:)

@wearhere
Copy link

wearhere commented Aug 27, 2016

Hey @benvinegar, cool to see this fixed. Will whitelistUrls automatically start filtering global exceptions once we upgrade?

@benvinegar
Copy link
Contributor

Will whitelistUrls automatically start filtering global exceptions once we upgrade to 3.4.0?

It already does? For normal exceptions (Error), at least. This changes it so that generic messages caught via captureMessage will also apply whitelistUrls (note that you need stacktrace:true set in config).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants