Not working with URI Signatures

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Sign the request (HMAC256 & Base64 Encoded) with an out of band secret
2. Append the signature to the URI
3. Issue a request

What is the expected output? What do you see instead?
I expect to see a list of records in JSON format.

What version of the product are you using? On what operating system?
CocoaRestClient 1.3.4 (9)
Mac OSX 10.8.2

Please provide any additional information below.
This is for development of an internal application (API). The app requires 
authentication through URI signatures (HMAC256 + Base64 encoded). If I execute 
the same request via cURL, I get the expected results. When running through 
CocoaRestClient, I continually get an Invalid URI Signature, which is an 
authorization exception from our application. 

curl -k -v 
"https://api.company.dev/v1/accounts?_signature=ry9zk1tpiYlRwlWAnZkrio7NQdUemJ6M
9D1tmBOswvk%3D" -H "X-ApiKey: 
50d7ee7de53a34a1ad1c17537892527cb0d731dc2a6b0c49719d5f28fc56ffd7" -H 
"Content-Type: application/json"

This works and returns records accordingly. When using that same URL in 
CocoaRestClient:

https://api.company.dev/v1/accounts?_signature=ry9zk1tpiYlRwlWAnZkrio7NQdUemJ6M9
D1tmBOswvk%3D

It will not work.

I have tried this with GET/POST/PUT/OPTIONS and DELETE.

Original issue reported on code.google.com by nateklai...@gmail.com on 7 Jan 2013 at 3:37

[GoogleCodeExporter]

Hmm interesting. What is the value you insert in X-ApiKey? Is that a signature 
generated using the request URL as a seed (effectively 'signing' the URL in the 
case of a GET)? Perhaps there's some sort of translation happen with the %3D at 
the end of the URL causing the signature to be invalid. Or do you think your 
application isn't getting the header at all? 

Original comment by mike.mat...@gmail.com on 8 Jan 2013 at 1:42

[GoogleCodeExporter]

Greetings Mike,
X-ApiKey is the public key used and present in all requests. This allows the 
system to identify the person in order to look up their out of band secret. The 
secret is what is then used to sign the request.

It effectively uses:

BASE64_ENCODE(HMAC_SHA256(HTTP_METHOD + REQUEST_URL + QUERY_STRING_PARAMS))

To generate the _signature that is present in the query string.

The application gets the API Key, as it's able to look up the person, so that 
header is sent - and it shows inside of the Request Headers.

The application gets the _signature from the query string params, otherwise our 
application would fail with an error about not having a _signature at all. 

I was looking to see if there was some sort of raw output or log that I could 
se the request being made through CocoaRestClient, but wasn't able to find 
anything.

It seems that maybe something is being escaped or translated differently when 
the request is made, but that's just a guess. I am able to complete a request 
with curl using the same parameters.

Thanks for your work on this, it is an extremely helpful application, 
regardless of this issue.

Hope this helps.

Peace,
Nate

Original comment by nateklai...@gmail.com on 8 Jan 2013 at 2:26

[GoogleCodeExporter]

Ah. For better or for worse (usually for worse), I'm using the http client 
library that Apple provides with the Cocoa libraries for making the http 
requests. This library tends to throw in a few HTTP headers of its own, such as:

Accept-Language: en-us
Accept: */*
Accept-Encoding: gzip, deflate

This probably means that the HMAC_SHA256 you calculated doesn't match. I need 
to work on suppressing this behavior, it's annoying and confusing. 

Original comment by mike.mat...@gmail.com on 8 Jan 2013 at 2:44

[GoogleCodeExporter]

Hey Mike,
I noticed something with the signatures. When I send the URL with curl, I have:

ry9zk1tpiYlRwlWAnZkrio7NQdUemJ6M9D1tmBOswvk%3D

as the signature.

When I inspected what my application was receiving when using CocoaRestClient, 
I noticed that the last % character was percent encoded:

ry9zk1tpiYlRwlWAnZkrio7NQdUemJ6M9D1tmBOswvk%253D

This is where I was getting a mismatch in signatures. I fixed this up in my 
application to ensure it will normalize all attributes, and now everything is 
working as expected.

Thanks for the assistance, and again, thanks for the awesome tool!

Peace,
Nate

Original comment by nateklai...@gmail.com on 8 Jan 2013 at 3:39

[GoogleCodeExporter]

Cool, sounds good. So any extra headers being added didn't cause a problem?

Original comment by mike.mat...@gmail.com on 10 Jan 2013 at 9:27

[GoogleCodeExporter]

Hey Mike,
After looking at it, I don't believe it has to do with the extra headers. I 
added those same headers with curl, and it worked, there was just something 
that was percent encoding characters - and I am not sure what it was.

I used the output as a test case in the application, then fixed how I handle 
escaping to account for it, so it worked after that.

Thanks again for your feedback and help - you can close this.

Original comment by nateklai...@gmail.com on 11 Jan 2013 at 1:53

[GoogleCodeExporter]

Original comment by mike.mat...@gmail.com on 12 Jan 2013 at 5:09

• Changed state: Invalid