Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Satellite 6.7 is not accepting the proxy password containing special characters like [ ] @ etc and test connection always fails.
Even if we just mention the password and submit, the password field remains blank.
Version-Release number of selected component (if applicable):
6.7.0
How reproducible:
Always
Steps to Reproduce:
1. Configure a squid proxy with the following details.
hostname: squid.example.com
port: 3128
proxy_username: proxyuser
proxy: password: test]satellite@password+
2. Go to Satellite GUI --> Infrastructure --> HTTP Proxies --> Fill up all the details including the proxy_password, in Test URL mention "https://aws.amazon.com" and then click on "Test Connection".
3. With all options filled up, submit the settings.
4. Now open the newly created proxy and look at the password field.
Actual results:
At Step 2, with test connection, you will get an error pop up saying "bad password component"
At Step 4, we will be able to see that the password is blank
Expected results:
Satellite 6.7 should be able to accept the password with special characters properly and allow it to save\user further from GUI.
Additional info:
If I use the same password from the command line, it will work just fine without escaping anything.
# curl -I --proxy-user proxyuser:test]satellite@password+ --proxy squid.example.com:3128 https://aws.amazon.com
HTTP/1.1 200 Connection established
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 210503
Connection: keep-alive
Server: Server
Date: Sun, 07 Jun 2020 14:10:24 GMT
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
x-amz-id-1: CR7RJ4KVMK4B3V4YM60K
Last-Modified: Thu, 04 Jun 2020 02:51:19 GMT
Set-Cookie: aws-priv=eyJ2IjoxLCJldSI6MCwic3QiOjB9; Version=1; Comment="Anonymous cookie for privacy regulations"; Domain=.amazon.com; Max-Age=94672800; Expires=Thu, 08-Jun-2023 08:10:24 GMT; Path=/
Set-Cookie: aws_lang=en; Domain=.amazon.com; Path=/
Vary: accept-encoding,Content-Type,Accept-Encoding,X-Amzn-CDN-Cache,X-Amzn-AX-Treatment,User-Agent
x-amz-rid: CR7RJ4KVMK4B3V4YM60K
X-Cache: Miss from cloudfront
Via: 1.1 e3e9665628588ed211b9d1805feda855.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: BOM51-C1
X-Amz-Cf-Id: AABZojxETJN_fdEvP1-AtLgyAnvy04MxYFEjxJoQrqn6ldVPIa4xQg==
TL;DR: There is no workaround, we will need to patch foreman and restclient. Foreman patch will be small, restclient patch was already written by ManageIQ folks and we'll just need to borrow it from them.
Notes:
There are two issues at play here.
The first is on our side. We try to stuff the user provided strings into an URI object, but that fails because special characters are not allowed there. If we escape the user provided strings first (turn '@' into '%40' and so on), this part should be resolved.
The other issue is restclient (the library we use for making http requests) does not unescape the proxy username and password, so even if we fix the first issue, then the escaped form will be sent to the proxy and the proxy will reject it. There is a PR[1] opened against restclient which fixes this, but last movement there was in October 2018, so I'm afraid we can't wait for this to be fixed there. Unless I'm missing something the only real option we have is to monkey-patch restclient the same way ManageIQ did[2].
[1] - https://github.com/rest-client/rest-client/pull/665
[2] - https://github.com/ManageIQ/manageiq/pull/18105
Verified:
Verified with:
- Satellite 6.9.6 snap 1
- katello-3.18.1-3.el7sat.noarch
- foreman-2.3.1.23-1.el7sat.noarch
Test steps:
- Create HTTP Proxy with special characters in password
(Go to Infrastructure > Http Proxies > Click on "New Http Proxy")
- Fill the details related to HTTP Proxy and click on "Test connection" button.
- Go to Administer > Settings > Content. Set "Default HTTP Proxy" setting.
- Refresh manifest.
- Enable and sync repositories.
Observations:
- "Test connection" button worked as expected.
- Manifest refresh, repository enable/disable and repository sync operation finished successfully.
Additional info:
- Tried following Http proxy password combination:
- t]se@pa+@#$%^
- test]satellite@password+
- t]se@pa+_~-*.,=[
- a?dd.}v{a
- test%5Dhttp_password%40password%2B
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Satellite 6.9.6 Async Bug Fix Update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:3628