Any way to filter parameters?
Closed this issue · 5 comments
Wondering if there is any support for filtering sensitive parameters in the request and the response.
Rails.application.config.filter_parameters += [:password] doesn't effect anything
Currently, there's not. The general idea is that filtering shouldn't be necessary since you should likely not be logging in a DEBUG level in a production/sensitive environment. At an INFO level, only the URL and status codes are logged.
On a possibly related note, it seems that trying to set a custom formatter proc on a Logger object actually causes an error:
log = Logger.new(some_file)
log.formatter = proc do |severity, datetime, progname, msg|
msg = msg.sub /Bearer(.*?)\"/, 'Bearer [FILTERED]"'
"[#{datetime}] - #{severity} -- : #{msg}"
end
client = OAuth2::Client.new(<creds>)
client.connection.response(:detailed_logger, log)
/Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/faraday-detailed_logger-2.1.2/lib/faraday/detailed_logger/tagged_logging.rb:70:in `tagged': undefined method `tagged' for #<Proc:0x007fc99c3564a8> (NoMethodError)
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/faraday-detailed_logger-2.1.2/lib/faraday/detailed_logger/middleware.rb:55:in `call'
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/faraday-0.9.2/lib/faraday/adapter/net_http.rb:56:in `call'
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/faraday-0.9.2/lib/faraday/request/url_encoded.rb:15:in `call'
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/faraday-0.9.2/lib/faraday/rack_builder.rb:139:in `build_response'
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/faraday-0.9.2/lib/faraday/connection.rb:377:in `run_request'
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/oauth2-1.3.1/lib/oauth2/client.rb:99:in `request'
from /Users/djberge/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/oauth2-1.3.1/lib/oauth2/access_token.rb:107:in `request'
Since the tagged method error appears to be a separate issue, I've created #7 to track it.
Closing this ticket. Filtering logged data should likely be the responsibility of the logger not the various libraries and parts of the application that might be unknowingly handling sensitive data.
As @djberg96 pointed out, you could provide a custom logger which is intelligent about what is sensitive and what isn't and it could dynamically filter out during the log calls.