Hi Taylor,

after doing some more detailed logging, i managed to figure out the
problem.

First I do the encoding of the post body, then the signature is being
build and attached to the post body.
I just forgot to encode the signature string, too, after attaching it
to the post body.
So everytime when the signature strings contained a slash or an equal
sign, like base64 tends to produce, the oauth failed.

Besides the encoding of the status texts was wrong. Just as I saw in
Abraham's Twitter PHP library I decoded %7E back to ~ in the final
string and oauth is happy. Otherwise, if the string contains a plain ~
it fails, still wondering why...

Thanks again for the support and sunny greetings from Hamburg Germany,
Felix.


On 14 Jun., 18:03, Felix Oldenburg <[email protected]>
wrote:
> Hi Taylor,
>
> thanks for many hints on tracking down the problem.
> I don't use any libraries, neither for Twitter, nor for oauth. I'm
> doing all by my self, thus printing out some debugging messages is
> fairly easy.
> As I'm able to do a status update some times successfully, I was sure
> to do everything correctly.
> Of cource, I inspected every detail, like the assembling of the base
> string and its signing.
> I followedhttp://dev.twitter.com/pages/authand I get the same
> results for the base string and the final signature string, when I use
> the same input as in the example.
> Even using special characters(space, exclamation mark, and so on..) in
> the text of the tweet is possible, as I already tweeted some cryptic
> posts - containing different special chars - to my wall.
> So I pressume my url encoding and signing process should be correct.
>
> https://api.twitter.com/oauth/request_tokenandhttps://api.twitter.com/oauth/access_token
> are the paths I use for acquiring the request and access token.
>
> The system clock of my Macbook is fine, I think, but I'll check that
> out on detail.
> Maybe I should recheck my timestamp and oauth_nonce generation code,
> because I don't check if a timestamp, or oauth_nonce is being used
> twice. Though I can't imagine what could go wrong, when simply using a
> unix timestamp.
> (Oh.. is it seconds or miliseconds ruby returns when using
> Time.now.to_i, I'd better check that out oO!!!)
>
> I'll check the timestamp thing and if that's not the problem, I'll
> post some detailed debug report tomorrow.
>
> Many thanks for your inspiring reply, Felix!
>
> On 14 Jun., 17:10, Taylor Singletary <[email protected]>
> wrote:
>
>
>
>
>
>
>
> > Hi Felix,
>
> > Are you using a specific OAuth library for the OAuth portion?
>
> > I would recommend adding a bit of logging around the OAuth token negotiation
> > process.. find out the signature base string, the exact URL you're
> > executing, and the Authorization header you're sending. Log the response
> > code and body of the response when it fails. With the main OAuth ruby gem
> > that's out there, some of these details are hard to come by because the
> > values are hidden in private methods (PSA to OAuth library developers: don't
> > do this), so you may need to monkey patch the OAuth gem here and there to
> > debug the values.
>
> > What you're mainly looking for is a specific pattern to your failed requests
> > for a request token -- is some value not being sent correctly? Do you have
> > some kind of problem where in certain conditions a variable you've set like
> > your consumer key gets unset somehow? Is your system clock reliable? Is the
> > library you're using to generate HMAC-SHA1 signatures doing the right thing?
> > Are you using the right kind of URL encoding? Are you accidentally sending
> > double parameters for something?
>
> > Verify that you're usinghttps://api.twitter.com/oauth/asthe base path for
> > the OAuth negotiation steps.
>
> > While there have been failures in the past in exchanging a request token for
> > an access token due to some lag, we're not aware of
> > anything specifically wrong with the process for fetching the request token.
>
> > @episod <http://twitter.com/intent/user?screen_name=episod> - Taylor
> > Singletary
>
> > On Tue, Jun 14, 2011 at 7:25 AM, Felix Oldenburg <
>
> > [email protected]> wrote:
> > > Hi twitter developing community,
> > > I'm using ruby( on rails) to do the oauth dance manually and finally
> > > call /1/statuses/update.json to update the status of an authorized
> > > user.
>
> > > Every single step during the oauth procedure is confirmed to be
> > > working.
> > > Actually I already tweeted some messages successfully. But for no
> > > obvious reason(to me), oauth sometimes fails at the very beginning
> > > while acquiring a request token. Then it just sais: "Failed to
> > > validate oauth signature and token".
>
> > > Then I retry it several times until it (suddenly) works.
> > > The next step, i.e. exchanging the request token for an access token,
> > > works perfectly every time.
> > > But when it comes to the actual status update(i.e. calling the /1/
> > > statuses/update.json endpoint) it sometimes fails, too, saying "Failed
> > > to validate oauth signature and token".
>
> > > Again I just retry a few times and all of a sudden it works.
>
> > > I don't change the code during this testing sessions, nor do i change
> > > the text I want to be tweetet.
> > > It just doesn't work sometimes.
> > > I can't reproduce this "unwanted behavior".
>
> > > Did Somebody have the same issue?
> > > Suggestions are also appreciated.
>
> > > Kind regards, Felix.
>
> > > --
> > > Twitter developer documentation and resources:https://dev.twitter.com/doc
> > > API updates via Twitter:https://twitter.com/twitterapi
> > > Issues/Enhancements Tracker:
> > >https://code.google.com/p/twitter-api/issues/list
> > > Change your membership to this group:
> > >https://groups.google.com/forum/#!forum/twitter-development-talk

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

Reply via email to