Special characters in password are double-encoded when client initialized with host as a string #712
Description
Steps to reproduce:
- Have a password that includes a special character such as
@. For example,p@assword. - Incorporate the password into a URL string to be passed to the client. Since "@" is a delimiter in URLs, it has to be percent-encoded, and you end up with a URL like
http://user:p%40ssword@127.0.0.1:9200/. - Initialize a client and try to search with it:
Elasticsearch::Client.new(url: 'http://user:p%40ssword@127.0.0.1:9200/').search('...')
Such a request will be rejected by the server because the password is percent-encoded again, presumably with the assumption that the original password value was not already percent-encoded.
The issue appears to be a combination of the approaches for parsing the host information when the client is initialized and generating the URL for the full request. In particular, the initial parsing (see https://github.com/elastic/elasticsearch-ruby/blob/v7.3.0/elasticsearch-transport/lib/elasticsearch/transport/client.rb#L202) uses URI.split in the case of a string, which does not perform any unescaping. That is, the password attribute will have the value p%40ssword and not p@ssword. Then, at https://github.com/elastic/elasticsearch-ruby/blob/v7.3.0/elasticsearch-transport/lib/elasticsearch/transport/transport/connections/connection.rb#L46, the password is encoded again. I assume the situation also applies to usernames in URLs.