excludedParams only works with exact match, and does not hide GET params from URL posted to HB

[benissimo]

When I manually trigger an error notification to HoneyBadger (HB) like this:

        Set<String> excludedParams = new HashSet<>();
        StandardConfigContext excludedParams.add("account_number");

        configContext = new StandardConfigContext();
        configContext.setApiKey("redacted...")
                .setExcludedParams(excludedParams);

        NoticeReporter reporter = new HoneybadgerReporter(configContext);
        reporter.reportError(t, o)

If the page triggering this error has an URL such as:

/page?foo=bar&account_number=secret&foo2=baz&account_number_confirmation=secret

Then when I visit HB to see the reported error, I find two problems:

1. (minor) account_number_confirmation is not filtered from the "params" section of HB. It would be nice if HoneybadgerReport's constructor allowed us to pass through our own exclusion strategy so that we could allow the use of regexes (or at the very least substrings) instead of only supporting exact matches.

2. (major) The full URL, with all querystring parameters, is listed in the URL for the origin of the error on HB. ie. The GET parameters are only stripped out in the "params" section, not in the URL itself, which contains all of them.

Granted, sensitive params shouldn't be passed around via GET to begin with, but it's inconsistent to filter them out of the "params" section while leaving them intact in the URL.

[joshuap]

I agree with both points. We've solved the GET URL filtering in Ruby; it's a little tricky because you have to parse out the query string and then reconstruct it with the sensitive keys filtered, but it's doable. Supporting regexps/substrings (or at least some kind of programmatic filter) would also be nice.

We don't have time to tackle this ourselves at the moment, however I'd accept a PR; otherwise we'll look at this in our next Java sprint. It may be better to start with #44 since it's easier and would at least provide a stopgap for people who don't want to risk leaking sensitive info in the query string.