Skip to content
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

setting an api key in the client constructor clobbers whatever transport options you're trying to send in #1940

Closed
svdasein opened this issue Oct 27, 2022 · 1 comment · Fixed by #1941

Comments

@svdasein
Copy link

Found this while trying to connect to a server with self signed certs. I did

transport_options = {
    ssl: {
      verify: false
    }

which didn't seem to have any affect (so I spent an hour or two trying different things - none seemed to make any difference).

I finally started digging into the library and found this little gem:

    def api_key(arguments)
      api_key = if arguments[:api_key].is_a? Hash
                  encode(arguments[:api_key])
                else
                  arguments[:api_key]
                end
      arguments.delete(:user)
      arguments.delete(:password)
      authorization = { 'Authorization' => "ApiKey #{api_key}" }
      if (headers = arguments.dig(:transport_options, :headers))
        headers.merge!(authorization)
      else
        arguments[:transport_options] = {
          headers: authorization
        }
      end
    end

In particular, "if (headers = arguments.dig(:transport_options, :headers))" will return nil if :headers is not defined, and once it does that it just completely overwrites the stuff I passed in with headers: authorization.

picandocodigo added a commit that referenced this issue Oct 28, 2022
When passing in `api_key` and `transport_options` that don't include headers to the client, the
api_key code would overwrite the arguments passed in for `transport_options`. This code fixes this,
checking if there are transport options and merging the auth headers with that instead.

Fixes #1940
@picandocodigo
Copy link
Member

Hi @svdasein, thanks for reporting this!
I have opened a Pull Request that addresses this bug: #1941
I'll backport this and it'll be available with version 8.5 which will be out soon.

Cheers!

picandocodigo added a commit that referenced this issue Oct 28, 2022
When passing in `api_key` and `transport_options` that don't include headers to the client, the
api_key code would overwrite the arguments passed in for `transport_options`. This code fixes this,
checking if there are transport options and merging the auth headers with that instead.

Fixes #1940
picandocodigo added a commit that referenced this issue Oct 28, 2022
When passing in `api_key` and `transport_options` that don't include headers to the client, the
api_key code would overwrite the arguments passed in for `transport_options`. This code fixes this,
checking if there are transport options and merging the auth headers with that instead.

Fixes #1940
picandocodigo added a commit that referenced this issue Oct 28, 2022
When passing in `api_key` and `transport_options` that don't include headers to the client, the
api_key code would overwrite the arguments passed in for `transport_options`. This code fixes this,
checking if there are transport options and merging the auth headers with that instead.

Fixes #1940
picandocodigo added a commit that referenced this issue Oct 28, 2022
When passing in `api_key` and `transport_options` that don't include headers to the client, the
api_key code would overwrite the arguments passed in for `transport_options`. This code fixes this,
checking if there are transport options and merging the auth headers with that instead.

Fixes #1940
picandocodigo added a commit that referenced this issue Oct 28, 2022
When passing in `api_key` and `transport_options` that don't include headers to the client, the
api_key code would overwrite the arguments passed in for `transport_options`. This code fixes this,
checking if there are transport options and merging the auth headers with that instead.

Fixes #1940
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants