Twitter.host should be "api.twitter.com" ?

[Harshad]

Hi,

Shouldn't Twitter.host be "api.twitter.com" ? (I am trying to build Dispatch from source with Twitter.host modified, but meanwhile I am asking here).

A bit of background. There are a few changes happening in Twitter's OAuth implementation and they are going to implement the oauth_verifier strictly henceforth. (It was effected for a while and then rolled back because it broke a lot of applications).

In my application (which uses Dispatch), I had ignored the oauth_verifier so far, by which I mean never parsed it nor sent it back to Twitter. But now that I am trying to change my application, I am not able to get the oauth_verifier from Twitter in the callback.

One of the reasons for this is reported to be wrong Twitter host. Hence this thread.

thanks,
Harshad

[n8han]

On 12/03/2010 06:38 AM, Harshad [via Databinder] wrote:
> Shouldn't Twitter.host be "api.twitter.com" ? (I am trying to build
> Dispatch from source with Twitter.host modified, but meanwhile I am
> asking here).

Hm. Did it used to be this host? I don't see anything in the commit
history where I just stupidly deleted the subdomain or anything.

I haven't used the Twitter API in a while, but I was thinking that when
I do fix the Twine demo app, I may as well implement it with the
streaming user timeline and add some hooks for that. I'll also take a
look at the other methods; it was never meant to be a complete interface
to the twitter API of course but what it does have ought to work. :)

> A bit of background. There are a few changes happening in Twitter's
> OAuth implementation and they are going to implement the
> oauth_verifier strictly henceforth. (It was effected for a while and
> then rolled back because it broke a lot of applications).

I updated dispatch.twitter.Auth to OAuth 1.0a some time ago, and it
worked. The verifier was supplied as a parameter in the callback url (or
onscreen, for oob).

> In my application (which uses Dispatch), I had ignored the
> oauth_verifier so far, by which I mean never parsed it nor sent it
> back to Twitter. But now that I am trying to change my application, I
> am not able to get the oauth_verifier from Twitter in the callback.
>
> One of the reasons for this is reported to be wrong Twitter host.
> Hence this thread.

Okay, I'll change the hostname and test it. Dispatch is about due for a
release anyway.

Nathan

[Harshad]

Update:

I tried the following:

1. Changed Twitter.host to "api.twitter.com"

2. Changed the definition of twitter.auth.request_token(consumer, callback_url) from

svc.secure / "request_token" << OAuth.callback(callback_url) <@ consumer as_token

to

svc.secure / "request_token" <<? OAuth.callback(callback_url) <@ consumer as_token

The second change was required because I think the api.twitter.com endpoint is more strict about the need for a callback_url (else it switches to a PIN based method), and the original Dispatch code was wrong.

I will try to make a patch and submit via GitHub.

[n8han]

On 12/03/2010 08:43 AM, Harshad [via Databinder] wrote:

> 2. Changed the definition of twitter.auth.request_token(consumer,
> callback_url) from
>
> svc.secure / "request_token" << OAuth.callback(callback_url) <@
> consumer as_token
>
> to
>
> svc.secure / "request_token" <<? OAuth.callback(callback_url) <@
> consumer as_token
>
> The second change was required because I think the api.twitter.com
> endpoint is more strict about the need for a callback_url (else it
> switches to a PIN based method), and the original Dispatch code was
> wrong.

What do you mean, wrong? The only difference I see is that one request
is a POST and the other is a GET. The oauth spec accepts either.

Nathan

[Harshad]

> I updated dispatch.twitter.Auth to OAuth 1.0a some time ago, and it
> worked. The verifier was supplied as a parameter in the callback url (or
> onscreen, for oob).

You are probably right that it works, when passing the callback url to request_token(). I just realised there was a minor goofup on my side. I was modifying a different line in my app's code and the actual line that was executed in my code was using the request_token without callback (hence oob).

However, I think the changes I proposed will be more forward - compatible since "api.twitter.com" is now the recommended endpoint.

[Harshad]

> What do you mean, wrong? The only difference I see is that one request
> is a POST and the other is a GET. The oauth spec accepts either.

Sorry, "wrong" was a strong word (after realising that I goofuped up and the original dispatch code works)

It feels "hackish" that you create a GET request and modify it on the fly to POST. I originally thought that this was breaking my app.

[n8han]

On 12/03/2010 08:57 AM, Harshad [via Databinder] wrote:
> Sorry, "wrong" was a strong word (after realising that I goofuped up
> and the original dispatch code works)
>
> It feels "hackish" that you create a GET request and modify it on the
> fly to POST. I originally thought that this was breaking my app.

No worries. dispatch.Request#POST works the same way behind the scenes.

I'm changing the host to "api.twitter.com". There's also a patch in the
fork queue, which I'm merging now, to put the callback in the header
instead of as a parameter. All the other oauth parameters are sent with
the header so it makes sense to change this one as well.

Nathan

[n8han]

Just pushed the changes and tested the oauth flow, seems fine.

Nathan