-
Notifications
You must be signed in to change notification settings - Fork 897
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
RestClient: Support percent encoded proxy user/pass #18105
RestClient: Support percent encoded proxy user/pass #18105
Conversation
require 'restclient/version' | ||
if RestClient::VERSION >= "2.0.0" && RestClient::VERSION <= "2.1.0" | ||
require 'restclient/request' | ||
RestClient::Request.module_eval do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, this autoloads rest client regardless if you're going to use it. I'm open to suggestions on how to avoid this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we prepend
the class like we do with our other patches?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to remember why Matthew convinced us a few years ago to use the module_eval thing instead of prepend. Either way, I think I'd be able to remove the require above it but both approaches would still autoload the constant for all processes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, nothing we can do about requiring it all the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will monkey patch the module itself. A prepend
will override the parent of this class.
Pretty sure we want don't want prepend
here.
reading the comments, I did not realize that we are monkey patching rest-client
code onto rest-client
because they haven't pulled the trigger in July 2017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, good point @kbrock regarding monkey patch vs. prepend. I don't think it matters here but module_eval
seems better for replacing a broken method vs. getting in "front" of it.
Yeah, rest-client is mostly dead. I've reached out to see if we can help maintain it but have heard nothing. Perhaps, we should fork it permanently at some point in the future. I don't know enough of it to be comfortable making changes throughout the codebase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll verify I can remove the require line too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't remove the require line since it doesn't autoload rest-client's request.
https://bugzilla.redhat.com/show_bug.cgi?id=1566615 Monkey patch RestClient for patch releases of rest-client 2.0.0. The underlying method, net_http_object, has not been modified since 2015 so it should be relatively safe to monkey patch this until the upstream PR gets merged/released. Upstream PR: rest-client/rest-client#665 To verify this works, run bin/rails console: Before: ``` irb(main):004:0> r = RestClient::Request.new(method: :get, url: 'http://127.0.0.1/api', proxy: 'http://%24myuser:%24%[email protected]') => <RestClient::Request @method="get", @url="http://127.0.0.1/api">=> <RestClient::Request @method="get", @url="https://127.0.0.1/api"> irb(main):002:0> r.net_http_object('host', 80).proxy_user => "%24myuser" irb(main):003:0> r.net_http_object('host', 80).proxy_pass => "%24%3Fxxxx" ``` After: ``` irb(main):004:0> r = RestClient::Request.new(method: :get, url: 'http://127.0.0.1/api', proxy: 'http://%24myuser:%24%[email protected]') => <RestClient::Request @method="get", @url="http://127.0.0.1/api">=> <RestClient::Request @method="get", @url="https://127.0.0.1/api"> irb(main):002:0> r.net_http_object('host', 80).proxy_user => "$myuser" irb(main):003:0> r.net_http_object('host', 80).proxy_pass => "$?xxxx" ```
d00e1f4
to
d2b0e32
Compare
Ok, ready for final review. |
Checked commit jrafanie@d2b0e32 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
@miq-bot add_label blocker |
…ent_encoded_proxy_user_password RestClient: Support percent encoded proxy user/pass (cherry picked from commit 5a784c3) https://bugzilla.redhat.com/show_bug.cgi?id=1566615
Hammer backport details:
|
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
Restclient as of version 2.1.0 uses provided credentials stored in a proxy URI object verbatim. If the credentials are escaped as they should be, then this leads to errors when we try to use the credentials because restclient sends the escaped form. There is a PR[1] in upstream restclient, which addresses this issue, but last movement there was in October 2018. ManageIQ folks decided to monkey patch restclient when they ran into the same issue, this commit is a loose adaptation of the original[1] and ManageIQ patches[2]. [1] - rest-client/rest-client#665 [2] - ManageIQ/manageiq#18105
https://bugzilla.redhat.com/show_bug.cgi?id=1566615
Monkey patch RestClient for patch releases of rest-client 2.0.0.
The underlying method, net_http_object, has not been modified since 2015
so it should be relatively safe to monkey patch this until the upstream
PR gets merged/released.
Upstream PR: rest-client/rest-client#665
To verify this works, run bin/rails console:
Before:
After: