elastic
Special characters in password are double-encoded when client initialized with host as a string
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%[email protected]:9200/. - Initialize a client and try to search with it:
Elasticsearch::Client.new(url: 'http://user:p%[email protected]: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.
I got hit by the same issue. After enabling Finge-grained Access control for an AWS ES domain and creating a master user with password containing special characters ([!@#$%^&*()]) I was getting Elasticsearch::Transport::Transport::Errors::Unauthorized: [401] Unauthorized error.
Only workaround I found was to use a password containing only URL safe characters ([a-Z0-9_-]).
Gem versions:
elasticsearch:7.5.0faraday:0.17.3
AWS Elasticsearch version: 7.4.2
