Faraday::Connectionexposes a few
attr_readers you can use to check these things. Check out https://github.com/lostisland/faraday/blob/main/lib/faraday/connection.rb#L21
Faraday::RackBuilder::Handlerobjects. The reason they show as class names in the Ruby console is because we override the
inspectmethod (see https://github.com/lostisland/faraday/blob/main/lib/faraday/rack_builder.rb#L42). If you try calling
conn.builder.handlers.first.classyou'll see the actual class and if you call
conn.builder.handlers.first.buildyou'll get an actual configured instance of the middleware.
headers: trueand was able to see other headers except "Authorization". Which is good actually just want to confirm. The API calls are still working so I guess you are not showing it intentionally for security reasons ?
builder.request :basic_auth, user, password
headers: true. I suspect what is happening here is that you've put the
:loggermiddleware BEFORE the
basic_authone :). The logger logs the request the moment it receives it, so if the
:basic_authmiddleware is added later in the stack, it won't have added the
Authorizationheader to the request yet. If this is what you want, then it's a pretty good solution on how to log the request without exposing the
builder.response(:logger, nil, headers: true, bodies: true, log_level: Rails.application.config.log_level) do |logger| logger.filter(/(Authorization)([^&]+)/, '\1[REMOVED]') end
filter_authflag to logger which does the filtering thing. I will be happy to open a PR.
filter_authsounds a bit too specific. Maybe a more generic method to filter headers? I’d suggest opening an issue before jumping on an implementation so we could discuss a proposal (how would that be used, how it will differ from the current
net-http-persistentteam and ask them about this. In the end, Faraday is just a wrapper on the adapters, so whatever they suggest as the best approach will work in Faraday as well