Honeybadger doesn't filter params for context info... about honeybadger-ruby HOT 6 CLOSED

Hey Christopher,

The purpose of context is to send additional pieces of data that you want to be visible per error. If you need to send request parameters, you can use the :parameters option, and those will get filtered. See https://github.com/honeybadger-io/honeybadger-ruby#going-beyond-exceptions

Since context should be added with the intent of the data being visible, I'm not sure it makes sense to filter it. I'm open to further discussion, though.

from honeybadger-ruby.

Joshua, thanks for the reply. I believe the reason we're using context is so we can set up information that will get sent for any exception that is raised in the proceeding code. It seems to be a bit more dynamic/flexible for certain situations to be able to create contextual data separately from the exception notification. (Think about a chain of calls that would descend into various library code... you might want to pass in some object attributes initially, and have that passed to honeybadger if an exception is raised somewhere in the library code)

Perhaps this is a slightly strange use case, but I imagine others might be doing something similar.

from honeybadger-ruby.

Btw, the above code is a bit sketchy... the following would be more in line with how the current params are being filtered (to handle "unserializable" elements)

module Honeybadger
  class Notice
    private 
    def set_context
      self.context = Thread.current[:honeybadger_context] || {}
      self.context.merge!(args[:context]) if args[:context]

      # To filter based on the params_filters specified in above config
      clean_unserializable_data(self.context)
      filter(self.context)

      self.context = nil if context.empty?
    end
  end
end

from honeybadger-ruby.

You're exactly right on the use case for context - it is meant to be "built up" over time as your code executes. But I'm still a little uncertain on the need to filter it - normally you shouldn't be adding parameters or other data that could be sensitive. It's more for things like a record ID, an email address, benchmark data, etc. Also, we only support a single-level hash for context. That said, I'll consider adding this - you're right that filtering would need to happen in Notice#set_context.

So that I can fully understand your use case, what sort of sensitive data do you need to filter, and how is it getting added to context currently?

from honeybadger-ruby.

Joshua, thanks again for the consideration; the example is simple:

# Assume process_and_save is involved enough to warrant asynchronous processing
# and that super_special_hash is sensitive (secret sauce research data 
# that we don't want in honeybadger or researchers' email accounts :)
BackgroundJobProcessor.process_and_save(super_special_hash)

from honeybadger-ruby.

I'm going to close this one out. I appreciate the request, but I think that since Honeybadger.context is meant to be called with explicit keys which you want to report, there's not need to filter it. The :parameters option can still be passed manually, and that is always filtered. I'd recommend looking into that. See Going beyond exceptions

Thanks!

from honeybadger-ruby.