Date   
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:

 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'}


September 30, 2014 at 3:57 PM
I get the following error (I made some adjustments because of formatting):

RestClient::BadRequest: 400 Bad Request



September 30, 2014 at 2:33 PM
RestClient.post "https://api.sendhub.com/v1/messages/?username=NUMBER\&api_key=API", { 'contacts' => [1111], 'text' => 'Testing }.to_json, :content_typ
e => 'application/json'
I hope this works.



September 30, 2014 at 2:24 PM
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
 

September 30, 2014 at 2:24 PM
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
 


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):

RestClient::BadRequest: 400 Bad Request


September 30, 2014 at 2:33 PM
RestClient.post "https://api.sendhub.com/v1/messages/?username=NUMBER\&api_key=API", { 'contacts' => [1111], 'text' => 'Testing }.to_json, :content_typ
e => 'application/json'
I hope this works.



September 30, 2014 at 2:24 PM
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
 

September 30, 2014 at 2:24 PM
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
 


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:

RestClient.post "https://api.sendhub.com/v1/messages/?username=NUMBER\&api_key=API", { 'contacts' => [1111], 'text' => 'Testing }.to_json, :content_typ
 e => 'application/json'
I hope this works.

On Sep 30, 2014, at 2:24 PM, Timothy Fong <timfong888@...> wrote:

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
 


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:

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
 


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.

I didn't realize REST Client had a `timeout` function, so I added an exception for `RestClient::RequestTimeout` and now it's all good.

Thanks!


2014-08-13 10:39 GMT+02:00 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

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?


On Wednesday, April 30, 2014, Larry Gilbert <larry@...> wrote:
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

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