Issues sending XML to OAuth and signing using Ruby OAuth Gem
[Submitted from the Google OAuth Ruby Team. If you couldn't help me, don't worry about it]
I am working on integrating a project with TripIt OAuth API and I am confused with a strange problem.
I authenticate fine, I store and retrieve the token / secret for a given user with no problem, I can even make GET requests to multiple services using the gem. But when I try to use one service, I need a POST for, I get a 401 "invalid signature" response.
I may not understand how to pass data to the AccessToken post, so here's a sample of my code:
xml = <<-XML
<Request>
<Trip>
<start_date>2008-12-09</start_date>
<end_date>2008-12-27</end_date>
<primary_location>New York, NY</primary_location>
</Trip>
</Request>
XML`
response = access_token.post('/v1/create', {:xml => xml},
{'Content-Type' => 'application/x-www-form-urlencoded'})
I tried this with and without xml string acceleration before getting started. The guys at TripIt seemed to think that maybe the xml param was not getting included in signature_base_string, but when I output this (from lib / signature / base.rb) I see:
POST & HTTPS% 3A% 2F% 2Fapi.tripit.com% 2Fv1% 2Fcreate & oauth_consumer_key% 3D% 26oauth_nonce% 3Djs73Y9caeuffpmPVc6lqxhlFN3Qpj7OhLcfBTYv8Ww% 26oauth_signature_method% 3DHMAC-SHA1% 26oauth_timestamp% 3D1252011612% 26oauth_token% 3D% 26oauth_version% 3D1.0% 26xml% 3D% 25253CRequest% 25253E% 25250A% 252520% 252520% 25253CTrip% 25253E% 25250A% 252520% 252520% 252520% 252520% 25253Cstart_date% 25253E2008-12-09% 25253C% 252Fstart_date 255025Cend25% 252Fstart_date% 2550253End25% 25253E2008-12-27% 25253C% 252Fend_date% 25253E% 25250A% 252520% 252520% 252520% 252520% 25253Cprimary_location% 25253ENew% 252520York% 252C% 252520NY% 25253C% 252Fprimary255% 25320Erip2% 25250A% 25253C% 252FRequest% 25253E% 25250A
This seems correct to me.
I am getting the signature (from the same file) and the output does not match the oauth_signature setting of the Auth header in lib / client / net_http.rb. It has been url encoded in the auth header. Is it correct?
Does anyone know if the stone is damaged / if there is something in there? I find it difficult to trace some of the code.
source to share