Hi All, Apologies for such a long post ..
I'm trying to construct a Signature Base String when calling an Enrolment API implemented for an LMS (Learning Mgt System). - I'm using code that we've written from scratch using ColdFusion 9/10. - I've got past the RequestToken / AccessToken stage and am ready to make calls (thought this would be the easy part!) - I can successfully perform GET requests with QueryString params but am having issues with POST With the POST requests, the main differentiating point is the data is supplied as a POST Body (or what I believe is referred to as "request entity-body" in "http://tools.ietf.org/html/rfc5849#section-3.4.1";). The reason why I believe this is: a) The entity-body is single-part (ie. Not a key/value pair) b) The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type c) I'm supplying a content-type header of "application/x-www-form-urlencoded" I should also note: - My code works with regular key/value POST values (being handled similar to QueryStrings in GET calls) being sent to Twitter. It's just this API that is giving me issues and as indicated the main difference is they handle their data in the POST Body not as key/value pairs. - In the following example the data is formatted like JSON but really it might as well be any other data ... - I've tried "oauth_body_hash" and confirmed I was producing the correct hash of the body but the generated signature didn't work and I think oauth_body_hash came about after this API was implemented .. so I'm sure the whole application/json specs should be ignored ... So, the HTTP Request I'm sending looks like this: POST http://<serviceProviderDomain>:80/api/enrolments HTTP/1.1 User-Agent: ColdFusion Connection: close Content-Type: application/x-www-form-urlencoded Authorization: OAuth oauth_consumer_key="<myConsumerKey>", oauth_nonce="13691140691369114069450", oauth_signature="TVe6NGghI0%2FI5dmD8AtATzSiU4k%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1369114069", oauth_token="", oauth_version="1.0" Content-length: 636 Host: <serviceProviderDomain> Proxy-Connection: Keep-Alive {"trainer":{"phone":"02 8888 8888","suburb":"Sydney","state":"NSW","address_two":"111 Name Street","surname":"Trainer1","first_name":"Jane","login":"jane.trainer1","mobile":"0400 000 000","post_code":2000,"email":"[email protected]","password":"abc123","address_one":"Unit 1 and 2"},"student":{"phone":"02 8888 8888","suburb":"Sydney","state":"NSW","address_two":"222 Name Street","surname":"Smith1","first_name":"John","login":"john.smith1","mobile":"0400 888 888","post_code":2000,"email":"[email protected]","password":"abc123","address_one":"Unit 1 and 2"},"unit_code":"XXXEEEESSS"} I'm getting a *403* Forbidden error which indicates an invalid signature. The service provider has implemented a library, which I believe they don't have the ability to debug to the signature generation level. They may be using a Ruby implementation of OAuth from http://oauth.rubyforge.org (as they pointed me that way but I don't know anything about Ruby at this stage). I build my signature using this format where the URLEncoded function is compliant with RFC-3986: POST + AMPERSAND URLEncoded(<APIEndPoint>) + AMPERSAND + URLEncoded( URLEncoded("oauth_consumer_key")=URLEncoded(<value>) + AMPERSAND + URLEncoded("oauth_nonce")=URLEncoded(<value>) + AMPERSAND + URLEncoded("oauth_signature_method")=URLEncoded(<value>) + AMPERSAND + URLEncoded("oauth_timestamp")=URLEncoded(<value>) + AMPERSAND + URLEncoded("oauth_token")=URLEncoded(<value>) + AMPERSAND + URLEncoded("oauth_version")=URLEncoded(<value>) ) + AMPERSAND + URLEncoded(*<body_entity>*) .. I encode this using HMAC-SHA1 .. My signing key constructed in the following format (where AccessTokenSecret is blank as they don't use 3-legged authentication): ConsumerSecret + AMPERSAND + AccessTokenSecret Is placement of the *body_entity* correct? ... because alphabetically, it would normally come before the oauth_* params. I got the placement, again from http://tools.ietf.org/html/rfc5849#section-3.4.1 where it says the order of building the "signature base string" is: 1. The HTTP request method in uppercase. For example: "GET", "POST" 2. An "&" character (ASCII code 38) 3. The base string URI after being encoded 4. An "&" character 5. The request parameters as normalized in Section 3.4.1.3.2, after being encoded (Section 3.6). *Questions ..* - Can anyone confirm my understanding? - Can anyone provide some test cases for me to validate? .. the Service Provider is wanting to help but technically cannot (I believe) .. Many thanks, Mick .. at wits end! -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
