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 |
Administrator
|
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 |
In reply to this post by 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. |
Administrator
|
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 |
In reply to this post by n8han
> 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. |
In reply to this post by n8han
> 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. |
Administrator
|
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 |
Free forum by Nabble | Edit this page |