ProxyOptionsobject by the
env.request.proxy, this should return a
http_proxy). This way you won't even need to pass it to the connection, it will be picked automatically for you!
Yeah I think that's clear, thanks for the context @MaryamAdnan3! The most immediate thing that comes to mind would be to have a "connection builder" method that returns a new faraday connection based on some parameters. Something like this:
def build_connection(retry_options: nil) Faraday.new(...) do |f| # other middleware f.request :retry, **retry_options if retry_options.present? # other middleware and adapter end end
You could then use this method to build your original Faraday connection object as well, so you won't need to copy over the handlers from one to another since the configuration will live inside this method. I'm not sure if this is possible in your specific case, but it would definitely be the cleanest way.
If you're not the one creating the original Faraday connection, then the only other option would be similar to what you're already doing, with the exception that you would need to always generate a new connection:
@handlersto see them)
This is definitely a "dirtier" solution, but unfortunately necessary if you don't control the original connection
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