-
Notifications
You must be signed in to change notification settings - Fork 173
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
Too easy to override params_filters defaults #264
Comments
Thanks for starting the discussion, @bhelx. There is certainly room for accidentally removing the defaults here. I'll need to give some thought to a potential fix. We could always append the default filters, for example. |
It should still definitely be possible in my opinion - as sometimes people want to send fields containing those strings through to bugsnag - so a potential solution is to make it more explicit. Or we could potentially have a config setting to enable/disable default params filters. |
We could also make a (breaking) change and support separate methods on config, like |
We are going to hold on this for now, though its worth noting for the next major release.. In the meantime, I'm updating the documentation to make this possibility clearer. |
Indicate the possibility of overwriting the params_filter defaults Related to #264
In the config object you allow setting some extra params filters via this API:
You also have some defaults that contain security related items:
https://github.com/bugsnag/bugsnag-ruby/blob/master/lib/bugsnag/configuration.rb#L41
This is good, but it seems very easy to mistakenly overwrite them. The API gives you direct access to the
params_filters
Set. So a one character mistake means you will be leaking sensitive information:Perhaps the API here can be slightly altered to disallow overriding security related defaults. I don't have any specific suggestions right now but wanted to open a discussion.
The text was updated successfully, but these errors were encountered: