To the poor unfortunate soul who finds themselves in a similar predicament:
1) http://term.ie/oauth/example/ This site has both client and server examples. Most useful (for testing clients) is it will tell you, in it's response body additional details about why it failed. This is much more helpful than the traditional "authorization failed" messages (I understand why real providers do this, but it makes testing hard) 2) Some great tools for testing your OAuth client include - http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/ This site allows you to enter your own data into the fields and it shows you what results you should expect. This was quite useful to me after I got past my above problem, because this site didn't include the original request_token steps. 3) I was originally confused as to why the base signature string is only partially URL encoded. For example, it may start with "GET&", without the & being encoded. Meanwhile, most of the rest of the string is encoded. Why the inconsistency? Not sure. But mind the difference. 4) I had been under the impression that all requests that require authorization (that is, everything but when the user logs into the provider site with their username/password) required POST http calls. I thought I saw that in the spec, but can't find it now. Regardless, some providers don't care which type you make. Others, like the twitter call to account/verify_credentials.xml, in fact WILL NOT WORK if you do a POST, but only a GET (as specified in the api docs for the twitter api). 5) This one is twitter specific: if you get to the point where you are getting "417 Expectation Failed" messsags, you're getting close! Turns out that for .NET solutions you need to set System.Net.ServicePointManager.Expect100Continue = false; (http:// blogs.msdn.com/shitals/archive/2008/12/27/9254245.aspx) regards, Matt On Jan 27, 5:00 pm, Matt <[email protected]> wrote: > I hate to continue replying to my own post, but I thought if I > provided the actual consumer tokens etc. might help: > > RequestTokenURL = "http://twitter.com/oauth/request_token"; > OAuthConsumerKey = "cY1cHq6P4VmrLVePpYWEw" > ConsumerSecretKey = "dZbuhYz8B5HzyHMVIS5M5djSmM3xVHEVrLinUKfzEY" > OAuthSignatureMethod = "HMAC-SHA1" > OAuthVersion = "1.0" > HTTPMethod = "POST" > OAuthTimeStamp = 1264624658 > OAuthNonce = "12345" > > The string that I am signing looks like this (no breaks): > > POST&http%3A%2F%2Ftwitter.com%2Foauth > %2Frequest_token&oauth_consumer_key%3DcY1cHq6P4VmrLVePpYWEw > %26oauth_nonce%3D12345%26oauth_signature_method%3DHMAC- > SHA1%26oauth_timestamp%3D1264624658%26oauth_version%3D1.0 > > The resulting signature is: R7WbI+2n9cEsZl9GzKNMJPWvo1w= > > The final authorization header content looks like this: > > OAuth realm="http://twitter.com/oauth/request_token";, > oauth_consumer_key="cY1cHq6P4VmrLVePpYWEw", oauth_nonce="12345", > oauth_signature="R7WbI%2B2n9cEsZl9GzKNMJPWvo1w%3D", > oauth_signature_method="HMAC-SHA1", oauth_timestamp="1264624658", > oauth_version="1.0" > > I am doing a POST using the authorization headers. But I have also > taken the generated results and converted into a query string, and did > a direct GET request from my browser (same result). I also tried doing > a POST with only "OAuth" and realm data in the Auth header, and doing > the rest in the query string (from inside FireBug in-browser). > > I'm at my wits end on this one - obviously the only error that we can > expect is "unauthorized", but there are *so* many things that can go > wrong in the signing/request process in OAuth that I might as well > throw a dart while blindfolded and expect to hit a bulls-eye. > > regards, > Matt -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
