Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    MaryamAdnan
    @MaryamAdnan3
    Thank you @iMacTia for helping me out here. so I have a requirement in which we have configured the Faraday connection object already with or without the retry_middleware and users can pass us retry middleware attributes separately like backoff_max, max_retries, etc and can ask us to override the existing connection object with the new retry_middleware. So basically if possible I want to override an existing connection object with new retry middleware attributes. but what I am getting from your conversation is that we must create a separate connection object with the new retry middleware and use it, we cannot override an existing one. I can create a new one but I want the passing Faraday connection objects properties in it as well along with the new retry configuration attributes being passed separately. Is there any way to do this? I am hoping I'm making myself clear here.
    Matt
    @iMacTia

    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:

    1. Create a new connection (new_conn)
    2. Configure the new connection with all the middleware from the old connection (check @handlers to see them)
    3. Add the retry middleware to the new_conn
    4. Remember to always add the adapter as the very last

    This is definitely a "dirtier" solution, but unfortunately necessary if you don't control the original connection

    Pedro M B Leal
    @pedrombl
    Hi team! :wave:
    We would like to use a gem that has requires an outdated version of Faraday (<1.0). I am trying to verify if the version 0.17.4 is stable and if there are no known security issues with it. The idea is to start using it this older version and upgrade the gem to use a newer version of Faraday in the neart future so our service can also updgrade Faraday.
    Matt
    @iMacTia
    Hi @pedrombl 👋! Thanks for asking. The core team is not aware any security vulnerability and even if one was discovered we’d most definitely release a patch version of the 0.x stream to address that (assuming it’s an important one, obviously).
    So I’d say as temporary solution it’s perfectly fine to use 0.17.x, just don’t expect any new features!
    Pedro M B Leal
    @pedrombl
    Great, thank you Matt!
    Wei Jun
    @Physium
    Hi there, i'm trying to create a class around Faraday so that i can set certain default connection variables across the team. Currently, i'm using builder to define my connection settings, is there a way i can pass builder as a class arguement if i ever want to override the connection settings on a new class initalization?
    Matt
    @iMacTia
    Hi @Physium, I'm not completely sure I understand, but the Rack::Builder is an internal class and it's not supposed to be sent around or used as an argument. My suggestion, assuming I actually understood the problem :smile:, is to have a connection "factory" or builder method like the one I described a few messages above
    Wei Jun
    @Physium
    Hi all, is there a way test if a connection is set up with the respective params/options/middleware in rspec? context i'm creating a base class of sort with a default initializer that sets up connection. At the same time this class takes in a set of options which allows me to adjust connection configs accordingly on initalization. I looking for a way to test if the connection in rspec is configured correctly based on the options parse in, is there a way i can go about doing it?
    Matt
    @iMacTia
    Hi @Physium, Faraday::Connection exposes 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
    params are exposed as-is and middleware is stored in the builder. As for options, there's a getter method here: https://github.com/lostisland/faraday/blob/main/lib/faraday/connection.rb#L222
    Wei Jun
    @Physium
    Hi @iMacTia! thanks for being so on point with your responses. I checked out the builder but noted that builders consist of a handler attr_reader which shows an array of middleware class names. There seem to be no way to go deeper to figure out if the middleware for eg is being configured accordingly with the respective options
    Matt
    @iMacTia
    @Physium I know, that's a bit confusing, but what you see is actually a list of Faraday::RackBuilder::Handler objects. The reason they show as class names in the Ruby console is because we override the inspect method (see https://github.com/lostisland/faraday/blob/main/lib/faraday/rack_builder.rb#L42). If you try calling conn.builder.handlers.first.class you'll see the actual class and if you call conn.builder.handlers.first.build you'll get an actual configured instance of the middleware.
    Appreciate this is not ideal, but it's the only way I'm aware of to check what you need
    Wei Jun
    @Physium
    Thanks @iMacTia ! i will give it a shot! shows how bad i am with ruby...
    Matt
    @iMacTia
    Not at all! If anything it shows how much room for improvement we have in our documentation 😅!
    raghu bhupatiraju
    @raghuvarmabh
    Hi @iMacTia I just upgraded to faraday 1.8. Do you automatically filter "Authorization" headers while logging. I did headers: true and 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 ?
    by the way i am using basic auth like this builder.request :basic_auth, user, password
    Matt
    @iMacTia
    @raghuvarmabh not to my knowledge, all headers should be logged if enabled with headers: true. I suspect what is happening here is that you've put the :logger middleware BEFORE the basic_auth one :). The logger logs the request the moment it receives it, so if the :basic_auth middleware is added later in the stack, it won't have added the Authorization header 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 Authorization header :D
    raghu bhupatiraju
    @raghuvarmabh
    Thats correct thanks for the inputs and great work on the gem. :thumbsup:
    raghu bhupatiraju
    @raghuvarmabh
    now I am seeing two logs for headers one with "Authorization" filtered and other without filtering for one POST API call.
    request: Accept: "application/json"
    Content-Type: "application/json"
    User-Agent: "Faraday v1.8.0"
    Authorization[REMOVED]
    and
    @iMacTia any guess why it is happening ? My goal is to filter the authentication tokens in logs.
    raghu bhupatiraju
    @raghuvarmabh
        builder.response :logger, nil, headers: true, bodies: true,
                         log_level: Rails.application.config.log_level
        builder.response :logger do |logger|
          logger.filter(/(Authorization)([^&]+)/, '\1[REMOVED]')
        end
    Matt
    @iMacTia
    @raghuvarmabh You're adding the logger twice this way, I guess that's unintentional, you can merge the two lines like this:
    builder.response(:logger, nil, headers: true, bodies: true,
                     log_level: Rails.application.config.log_level) do |logger|
      logger.filter(/(Authorization)([^&]+)/, '\1[REMOVED]')
    end
    raghu bhupatiraju
    @raghuvarmabh
    ya thats the issue for seeing duplicate logs. Thanks again @iMacTia for quick resonse.
    Will it be helpful to add a filter_auth flag to logger which does the filtering thing. I will be happy to open a PR.
    Matt
    @iMacTia
    You’re welcome @raghuvarmabh 🙌!
    filter_auth sounds 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 filter method, …)
    Dan Milne
    @dkam
    Hi guys - I have a problem where a header I'm adding to a request "authorizationToken" is having its case changed to "Authorizationtoken". The server apparently is case sensitive and returns a 500 when the case is changed.
    Matt
    @iMacTia
    Hey @dkam, that might be because you're using symbols to set headers or a known issue affecting Net::HTTP, I posted some more details in this comment: https://github.com/lostisland/faraday/issues/747#issuecomment-439864181
    Eddie Cheung
    @eddiecheung-shopify
    Hi guys, I am new to use Faraday connection for sending POST request. Based on some research, I notice that using net_http_persistent adapter (instead of the Faraday.default_adapter (which is net_http according to the Faraday documentation) will improve performance due to reusing the same connection. Basically, I would like to learn the best practice on some of the setting (like pool_size, idle_timeout, keep_alive and max_requests) for net_http_persistent adapter in order have a high performance and stable Faraday connection. Thanks in advance.
    Matt
    @iMacTia
    Hi @eddiecheung-shopify and thanks for joining! I personally don't have expertise in every Faraday adapter (hence why we recently went through the work of splitting them into their own repos), so I don't feel like the best person to provide "bets practices values" for their configuration. I hope someone here (@/all) will be able to help, but otherwise you could reach out to the net-http-persistent team 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
    1 reply
    Matt
    @iMacTia

    Announcement

    We've decided to move over to GitHub Discussions for community discussions on getting help and asking questions.
    The Faraday core team will not be monitoring this chat anymore, but you're more than welcome to stay and continue the discussion if you prefer.
    If you want to reach out to the Faraday core team, you can find us here
    Samuel Williams
    @ioquatix
    @eddiecheung-shopify you should check out the async backend.