whichdigital / active-rest-client

ActiveRestClient API Client
https://rubygems.org/gems/active_rest_client
MIT License
386 stars 44 forks source link

Update ReadMe to reflect that only PUT and POST sign requests #114

Closed jgujgu closed 8 years ago

jgujgu commented 8 years ago

On my web side, I set

ActiveRestClient::Base.api_auth_credentials(ENV["id"], ENV["secret"])

as noted, and set my api side to have a before_action that involved

ApiAuth.authentic?(request, ENV["secret"])

However, the ApiAuth gem only allows for PUT and POST requests to be signed (https://github.com/mgomes/api_auth/blob/c80c998ccedf303ae3e14c4481cfe40e959ee94e/lib/api_auth/request_drivers/rest_client.rb#L35). I think the documentation could be updated to note that only PUT and POST requests will be signed, instead of how it is currently, noting that all request will be signed: Then simply configure Api-Auth one time in your app and all requests will be signed from then on.

jgujgu commented 8 years ago

PR: https://github.com/whichdigital/active-rest-client/pull/115

andyjeffries commented 8 years ago

ActiveRestClient isn't being actively maintained. I forked the project (as the original author of most of the code) and am maintaining it as Flexirest. I've fixed it in v1.2.12 of that project. https://github.com/andyjeffries/flexirest

jgujgu commented 8 years ago

Thanks Andy. I'll use Flexirest.

kjg commented 8 years ago

@andyjeffries Just for the record, @jgujgu was mistaken. All requests are signed, not just POST/PUT.

The link provided in the original comment shows the method that populates the Content-MD5 header (which is just one portion of the canonical strings that api-auth uses in its HMAC calculation). The Content-MD5 header is only populated on requests that have a content-body (so NOT GET or DELETE requests for example). However the Authentication signature is still calculated and populated on GET requests, it just will have an empty Content-MD5 value.

In other words, changing the docs to say only PUT/POST requests will be signed would be incorrect.

Hopefully that makes sense. Let me know if I can provide any further clarification. Thanks!

andyjeffries commented 8 years ago

Fantastic, thanks @kjg, I don't use ApiAuth myself so wasn't aware of this. I'll put the documentation back the way it was.