Comments (6)
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.
Related Issues (20)
- Add support for Hanami HOT 1
- `Honeybadger.notify` requires `error_message` to be specified when using a Hash HOT 4
- Documentation and source mismatch with Rails.error.record HOT 1
- `Honeybadger::Config#respond_to?` Always Returns true
- Help suppressing a certain error HOT 4
- Honeybadger CLI errors when the deploy command is called with any option HOT 3
- Minitest: Test Backend Notices Not Added to `Honeybadger::Backend::Test` HOT 9
- Invalid class_name param in documentation HOT 1
- Use nested context from objects where available
- Sidekiq 7.1.5 and later changes number of arguments for error handlers
- Add check-in configuration sync HOT 2
- Automate releases with Github Actions
- Flaky test in JRuby test matrix entry
- Allow check-ins to be made by slug as well as id. HOT 8
- Avoid bundling unnecessary dependencies in published gem HOT 3
- Exceptions raised in jobs from Solid Queue are not automatically reported HOT 10
- Sanitizer#filter_key? returns a warning for Numeric hash keys HOT 5
- ActiveJob premature reporting HOT 2
- ActiveJob rescued exceptions should not be reported HOT 2
- Honeybadger.context returns Honeybadger::Agent when passing a block
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from honeybadger-ruby.