|
Version 2.1.0
Andy Brody
Hi folks,
The rest-client 2.1.0 final release is now available. https://rubygems.org/gems/rest-client/versions/2.1.0 https://github.com/rest-client/rest-client/releases/tag/v2.1.0 Notable changes in this release: There is a new dependency on the `http-accept` gem, which is used for parsing Content-Type charset headers. This works around a bad memory leak and possible segfault introduced in MRI Ruby 2.4.0 and fixed in Ruby 2.4.2. (#615) Use mime/types/columnar from mime-types 2.6.1+, which is leaner in memory usage than the older storage model of mime-types. (#393) Add a `:log` option to individual requests. This allows users to set a log on a per-request / per-resource basis instead of the kludgy global log. (#538) Log request duration by tracking request start and end times. Make `log_response` a method on the Response object, and ensure the `size` method works on RawResponse objects. (#126) - `# => 200 OK | text/html 1270 bytes, 0.08s` Make the logs more configurable in raw_response streaming mode so rest-client no longer emits log messages on each chunk of data. Drop custom handling of compression and use built-in Net::HTTP support for supported Content-Encodings like gzip and deflate. Don't set any explicit `Accept-Encoding` header, rely instead on Net::HTTP defaults. (#597) Note: this changes behavior for compressed responses when using `:raw_response => true`. Previously the raw response would not have been uncompressed by rest-client, but now Net::HTTP will uncompress it. Fix Netrc support to respect existing Authorization headers, regardless of letter case. (#550) Improve handling of payload objects using ParamsArray or Payload classes. (#508, #603) The full changelog is available here: https://github.com/rest-client/rest-client/blob/v2.1.0/history.md As usual, please file any bugs at https://github.com/rest-client/rest-client/issues Cheers, Andy
|
|
|
|
rest-client version 1.6.13 backdoored with malicious code [CVE-2019-15224]
Andy Brody
Hi all,
On August 14, attackers published a series of rest-client versions from 1.6.10 to 1.6.13 using the credentials of a rest-client maintainer whose RubyGems.org account was compromised. The affected versions were downloaded a small number of times (~1000). On August 19, Jussi Koljonen observed the malicious gem version and created an issue. Later that day, the RubyGems security team yanked the offending gem version and locked the affected maintainer's account. Several other gems were similarly affected. https://github.com/rubygems/rubygems.org/wiki/Gems-yanked-and-accounts-locked#19-aug-2019 The malicious backdoor in version 1.6.13 would activate in Rails installations where Rails.env started with "p" (as in "production"). It would then download code from a Pastebin.com URL and execute it. The pastebin is now gone, but it reportedly phoned home to execute instructions from mironanoru DOT zzz DOT com DOT ua, which has also disappeared. This was reportedly used to mine cryptocurrency, but could have been used for any purpose. Most rest-client users were not affected because the 1.6.x series is very old and was superseded by 1.7.0 in 2014. Only users who pin to 1.6.x and updated to 1.6.13 in the last week could have been affected, and only then in Rails production environments. To search for Gemfile.lock files containing one of the malicious versions, you may find this grep command useful: cd dir-to-search grep --include='Gemfile.lock' -r . -e 'rest-client (1\.6\.1[0123])' The rest-client maintainers will take a number of steps in response to this incident: First, we have released a new version 1.6.14 so that users who are for some reason unable to upgrade to a modern version of rest-client can have confidence in the security of a `bundle update`. Second, we will establish security practices that we expect of maintainers, such as enabling two-factor authentication on RubyGems.org accounts (available since last year). Third, we will seek to adopt policies for maintainer activity and continuity, and ideally seek one or two new active maintainers. The latest release prior to today was in 2017, so it is not a surprise that rest-client has several maintainers who have not been active in many years. The RubyGems.org team is also in the process of making a number of upstream security improvements in response to the increasing prevalence of attacks targeting popular open source libraries. These include: - Adding web UI to show which specific user pushed or yanked a given gem release. - Adding email notifications to owners of new gem pushes. (currently disabled due to using a free email provider plan) - Validating passwords against a list of known compromised passwords. (in progress) You can see this work in progress or make your own contributions at https://github.com/rubygems/rubygems.org/ Thanks for your patience and support, Andy References: https://github.com/rest-client/rest-client/issues/713 CVE-2019-15224
|
|
|
|
rest-client 2.0.2
Andy Brody
Hi folks,
Today the rest-client 2.0.2 release is available with one minor bugfix of an excessive warning that was introduced in version 2.0.1. https://rubygems.org/gems/rest-client/versions/2.0.2 https://github.com/rest-client/rest-client/releases/tag/v2.0.2 Users will no longer see a spurious warning when an auto-generated header and a user-set header collide but have the same value anyway. (#578) The full changelog is available here: https://github.com/rest-client/rest-client/blob/v2.0.2/history.md As usual, please file any bugs at https://github.com/rest-client/rest-client/issues Cheers, Andy
|
|
|
|
rest-client 2.0.1
Andy Brody
Hi folks,
Today the rest-client 2.0.1 release is available with a few minor changes. https://rubygems.org/gems/rest-client/versions/2.0.1 https://github.com/rest-client/rest-client/releases/tag/v2.0.1 This release fixes compatibility with OpenSSL 1.1.0 by dropping the old check for weak default TLS ciphers, and using the built-in Ruby defaults. Ruby versions from Oct. 2014 onward use sane defaults, so this is no longer needed. (#573) Users will also now see warnings if auto-generated headers from the payload, such as Content-Type, override headers set by the user. This is usually not what the user wants to happen, and can be surprising. (#554) The full changelog is available here: https://github.com/rest-client/rest-client/blob/v2.0.1/history.md As usual, please file any bugs at https://github.com/rest-client/rest-client/issues Cheers, Andy
|
|
|
|
rest-client 2.0.0.rc4
Andy Brody
Hi all,
The fourth release candidate for rest-client 2.0.0 is now available for testing from GitHub and RubyGems.org. https://rubygems.org/gems/rest-client/versions/2.0.0.rc4 https://github.com/rest-client/rest-client/releases/tag/v2.0.0.rc4 The 2.0.0 major release is largely API compatible with the 1.x series, but it makes several major changes and represents a large amount of work by many different contributors. Please file any bugs at https://github.com/rest-client/rest-client/issues ! If there are no major bugs, this should be the last release candidate before a final 2.0.0 release. Most notable changes: - This release drops support for Ruby 1.9 and below, which was necessary to support mime-types 3.x. - Response handling has been refactored for clarity. RestClient::Response objects are now a subclass of String rather than a String object with response functionality mixed in. This makes it much more obvious what type of object you're working with, and avoids many gotchas and bugs around object serialization and other surprises. Call .to_s or .body on response objects to get a plain String object. - Responses now respect Content-Type charset headers. A valid charset header will result in a response with an appropriate string encoding. For example, `Content-Type: text/plain; charset=EUC-JP` will result in a body String encoded with `Encoding::EUC_JP`. - Cookie processing has been completely rewritten to use cookie jars. The `:cookies` option to RestClient::Request now accepts HTTP::CookieJar objects in initialization. The prior API still works, but will put the cookies in a cookie jar under the hood. This cookie jar is also used for responses and redirection, allowing for browser-like handling of cookies throughout. Request and Response objects now expose a `#cookie_jar`, which is recommended for use instead of `#cookies`. - The exceptions raised on timeouts have changed. Instead of RestClient::RequestTimeout (which is still used for HTTP 408 "Request Timeout"), network timeouts will now raise either RestClient::Exceptions::ReadTimeout or RestClient::Exceptions::OpenTimeout, both of which inherit from RestClient::Exceptions::Timeout. This class also makes the original wrapped exception available as `#original_exception`. - Redirect handling has been improved in a few ways: 1. RestClient::MaxRedirectsReached has been removed in favor of the normal rest-client HTTP response exceptions. These exceptions expose the response object with `#response`, making it now possible to handle these responses normally. 2. Response objects now have a `#history` method that exposes a list of prior responses from an HTTP redirection chain. Previously it was not possible to know what earlier responses were encountered after following redirection. 3. It is now much easier to manually follow redirection, by setting `max_redirects: 0`, catching the ExceptionWithResponse, and calling `err.response.follow_redirection`. - HTTP params processing for GET and POST requests refactored: There is new, more sophisticated code for handling GET/POST params passed as a structured hash. Both GET and POST now use common code in RestClient::Utils: `.encode_query_string` and `.flatten_params`. You can now pass deeply nested hashes and arrays, empty values, even null, and rest-client will try very hard to render the params in a way that will be intelligible to Rack or PHP based servers. (There is no standard defining this behavior, so we had to ad lib.) You can also use the new RestClient::ParamsArray class to pass multiple keys with the same name or where the ordering is significant. There were also various bugs squashed and enhancements added: - IPv6 address support was corrected in various places. - Multiple HTTP response headers with the same name are now joined per RFC 7230. - HTTP proxies can now be configured or disabled on a per-request basis. - before_execution_procs can now be added on a per-request basis. - Streaming request payloads will now require dramatically less memory. - A useful User-Agent header is now added identifying the agent as rest-client by version. - Several gotchas and more complicated rest-client use cases are now documented in the README. Please see https://github.com/rest-client/rest-client/blob/v2.0.0.rc4/history.md for a complete list of changes. Cheers, Andy
|
|
|
|
rest-client 1.8.0 released with security fixes
Andy Brody <andy@...>
Hi all,
Rest-client 1.8.0 is now available on GitHub and rubygems.org: https://rubygems.org/gems/rest-client/versions/1.8.0 https://github.com/rest-client/rest-client/releases/tag/v1.8.0 This release fixes an issue with cookie processing that could lead to session fixation or cookie disclosure attacks. This issue has been assigned CVE-2015-1820, and was discovered by the rest-client team following a similar issue affecting python-requests. https://github.com/rest-client/rest-client/issues/369 The problematic behavior was introduced in rest-client 1.6.1: any Set-Cookie headers present in an HTTP 30x redirection response are blindly sent to the redirection target, regardless of domain, path, expiration, or secure cookie settings. All subsequent 1.6.x and 1.7.x releases are affected. This issue could not be easily fixed without substantial changes to rest-client's cookie processing. Rest-client now depends on the http-cookie gem, which implements RFC 6265 compliant support for cookies in a browser-like way. As a result, the behavior of rest-client in 1.8.0 differs from previous releases in that it now omits invalid or incorrectly targeted cookies from the Response#cookies hash. While the new behavior is more secure and standards compliant, this may break some use cases. Please use `headers[:set_cookie]` on response objects to see the raw headers if this is problematic. Otherwise, the changes in behavior for 1.8.0 should be transparent. Cheers, Andy
|
|
|
|
rest-client 1.7.3 released
Andy Brody <andy@...>
Hi all,
Rest-client 1.7.3 is now available on GitHub and RubyGems.org: https://rubygems.org/gems/rest-client/versions/1.7.3 https://github.com/rest-client/rest-client/releases/tag/v1.7.3 There are two minor changes: - rest-client will no longer log the password from a URI even if logging is enabled (issue #349, also reported as OSVDB-117461) - rest-client no longer monkey patches MIME::Types (the functionality should be unchanged) Cheers, Andy
|
|
|
|
How do i upload a file using form-data?
Srikanth Hugar <srikanth.hugar@...>
Hello, I would like to write a REST client to upload a document using form data. I tried multiple options options, but could not help. REST CLIENT fails: self.class.post(path, :documentName => File.new('E:\code\css\trunk\qa\dev-test\resources\webrtc_overview.pptx'), :json => '{"ownerId":"59c1393f69d05905dcfc8993c0c659fd","outputType":"PDF"}', :headers => headers, :multipart => true ) from above request, server throws the error. My postman request headers which is successful looks something like below: SUCCESS from POSTMAN Content-Type:multipart/form-data Request Payload ------WebKitFormBoundarydvTARb1P7x7rBdOA Content-Disposition: form-data; name="documentName"; filename="webrtc_overview.pptx" Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation ------WebKitFormBoundarydvTARb1P7x7rBdOA Content-Disposition: form-data; name="json" {"ownerId":"59c1393f69d05905dcfc8993c0c659fd","outputType":"PDF"}
|
|
|
|
Re: convert Curl with headers -H and -- data to RestClient
Timothy Fong <timfong888@...>
Pretty close, here is what
finally worked:
toggle quoted messageShow quoted text
url_sms = "https://api.sendhub.com/v1/messages/?username=#{NUMBER}\&api_key=#{APIKEY}" smspacket = {:contacts => ["#{contact_id}"], :text => "#{botresponse}" }.to_json response = RestClient.post url_sms , smspacket, {:content_type => 'application/json'}
|
|
|
|
Re: convert Curl with headers -H and -- data to RestClient
Timothy Fong <timfong888@...>
I get the following error
(I made some adjustments because of formatting):
toggle quoted messageShow quoted text
RestClient::BadRequest: 400 Bad Request
|
|
|
|
Re: convert Curl with headers -H and -- data to RestClient
Tim Fong <timfong888@...>
Hi I tried this but it an auth error. Let me try again. Sent from my iPhone
On Sep 30, 2014, at 2:33 PM, Kannan Manickam <kannan@...> wrote:
|
|
|
|
Re: convert Curl with headers -H and -- data to RestClient
Kannan Manickam <kannan@...>
RestClient.post "https://api.sendhub.com/v1/messages/?username=NUMBER\&api_key=API", { 'contacts' => [1111], 'text' => 'Testing }.to_json, :content_type => 'application/json' I hope this works.
On Sep 30, 2014, at 2:24 PM, Timothy Fong <timfong888@...> wrote:
|
|
|
|
convert Curl with headers -H and -- data to RestClient
Timothy Fong <timfong888@...>
How do I convert the following to Restclient?
curl -H "Content-Type: application/json" -X POST --data '{"contacts" : [1111],"text" : "Testing"}' https://api.sendhub.com/v1/messages/?username=NUMBER\&api_key=APIKEY
|
|
|
|
Multipart Payload Content Types for individual parts
Kannan Manickam <kannan@...>
Hello,
I've been trying to use multipart payload to send a message with multiple parts each with an 'application/json' type and there is currently no way of achieving this. Is this currently not supported? I am forced to use a monkey-patched version of rest-client. Thanks, Kannan.
|
|
|
|
Re: Dealing with offline APIs
Frank Tellefsen <tellefsenfrank@...>
Apologies for not researching the matter more thoroughly before resorting to this list. Thanks!I didn't realize REST Client had a `timeout` function, so I added an exception for `RestClient::RequestTimeout` and now it's all good.
|
|
|
|
Dealing with offline APIs
Frank Tellefsen <tellefsenfrank@...>
Hi, I'm using REST Client to fetch some stuff from this API (main_controller.rb @ http://runnable.com/U-QJCIFvY2RGWL9B/pretty-json-keys). However, if the API goes offline, my whole app will time out. Is there a way to prevent that? I'd hate to think I should have gone with jQuery from the start. Thanks! Frank
|
|
|
|
bugfix rest-client 1.7.1 and 1.7.2 released
Andy Brody <andy@...>
Hi folks,
We've shaken a few bugs out of the 1.7.x branch. Errors on duplicate CA certificates on Windows are now gracefully handled. Rest-client will now allow but not depend on mime-types 2.0. A large number of gems had dependencies on mime-types ~> 1.x, which meant that they were incompatible with the pin on ~> 2.0 that was temporarily introduced by rest-client 1.7.0. Cheers, Andy
|
|
|
|
rest-client 1.6.8 and 1.7.0 released
Andy Brody <andy@...>
The first new releases of REST Client in quite some time are now
available on RubyGems! Please find the changelog on GitHub at https://github.com/rest-client/rest-client/blob/v1.7.0/history.md On the 1.6.x branch, the 1.6.8 release represents three years worth of sundry cleanup and test improvements. Tests now run for the major branches on Travis CI. This branch is now in maintenance-only mode, and it will be the last line of releases to support Ruby 1.8.7, which is itself very much on the way out. The 1.7.0 release contains a variety of new minor features especially related to SSL support, and breaks backwards compatibility in a few minor ways: - From rest-client >= 1.7.0, support for Ruby 1.8.7 has been dropped. This allowed an upgrade to mime-types 2.0. For continued Ruby 1.8.7 support, please use releases in the 1.6.x series and pin your dependencies to '~> 1.6.8'. - For HTTPS connections, SSL peer verification is now *enabled* by default. We have made an effort to make rest-client behave much more like browsers by choosing secure defaults. Rest-client will check certificates against the system-provided certificate authorities on Linux, OS X, and Windows. It will also attempt to select a strong set of SSL cipher suites. And there are several new configuration options for advanced usage including SSL ca_path, cert_store, and verify_callback parameters. In order to support the Windows system CA store, there is now a separate build for Windows that pulls in the `ffi` gem. These releases represent years of work from a very large number of contributors, but thanks especially belong to Larry Gilbert and Matt Manning for all their work. We aim to pick up the pace of development now that the long freeze on releases has thawed! Please submit your pull requests on GitHub: https://github.com/rest-client/rest-client/pulls Warmly, Andy
|
|
|
|
Re: rest-client 1.6.8.rc1 and 1.7.0.rc1
Jonathan Brown <johnnybrown7@...>
Unsubscribe?
toggle quoted messageShow quoted text
On Wednesday, April 30, 2014, Larry Gilbert <larry@...> wrote:
|
|
|
|
rest-client 1.6.8.rc1 and 1.7.0.rc1
Larry Gilbert <larry@...>
Hello Ruby REST Client fans, The rest-client gem has been long, long overdue for a new release, so I just wanted to let you all know that prereleases are finally hitting the wire.
1.6.8.rc1 is published now, but don't get too excited unless you are one of those poor souls stuck with Ruby 1.8.7 for whatever reason. That's because the 1.6 branch is being maintained only to keep compatibility with 1.8.7, so it will only be receiving fixes for bugs and security issues.
Anyone using Ruby 1.9.3 or newer should not pay too much attention to 1.6.8.rc1. Wait for 1.7.0.rc1 and try that out instead. It contains actual new features! And even though it should be compatible with code written for rest-client ~> 1.6.0, I'd love to see as many gem authors as possible whose gems depend on rest-client try out the prerelease to shake out any unforeseen problems.
I was going to wait until the "official" releases to say this, but no time like the present... Thank you to everyone who's contributed to the code (if your name isn't in the "AUTHORS" file, let us know). Thanks to Julien Kirch for all his work in keeping the gem alive. And special thanks to Andy Brody and Matt Manning for the huge amount of work they've put into getting us to this point; honestly, these releases probably would not be happening without their help. (Hope I haven't forgotten anyone.)
Cheers, and stay RESTful. B-) Larry Gilbert Computer geekery since 1976
|
|
|
