Matt mentioned this was coming May 28 [1]. Most of the problems we have hear of came from the fact that the Ruby OAuth library sent a oauth_callback parameter without the knowledge of the developer.
Regardless, we are certainly sorry to see you go. Please feel free to email us [2] if you have any parting suggestions. 1. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/1c48fedf4ae7ed52/5ac22db230c7a95a?lnk=gst&q=oauth+pin#5ac22db230c7a95a 2. http://apiwiki.twitter.com/Support Thanks, Doug On Sun, Jun 21, 2009 at 9:51 AM, app<apphac...@gmail.com> wrote: > > I think it's pretty lousy that this change was pushed with no warning > at all. It's discouraging when you see that your app is failing after > it had been working just fine with no code change. I didn't even know > my app was broken until I attempted to use it. Now if I want this > thing to work, I have to spend time to fix an app that was fine and I > hadn't worked on in a while. And then what happens two weeks from now? > You're going to issue another oauth update that breaks my app again? > Well guess what. I'm not fixing it, and I'm not developing on your api > anymore. Bad form. And for the record I wrote the oauth implementation > I'm using myself and I do not send a oauth_callback=oob parameter. > > I have got better things to do than deal with this. I should have just > gone with http auth instead of willingly submitted myself to the > continued abuse you subject on conscientious developers who went with > oauth. > > On Jun 9, 4:23 pm, Doug Williams <d...@twitter.com> wrote: >> Today we deployed code that implemented the changes that accompanied the >> update to the 1.0a OAuth specification. LuckyCal has a great article on the >> subtle differences that come with the update [1] so please peruse this >> article if you are getting 401 errors with your implementation. >> >> Callbacks for non-desktop apps are now supported with these rules: >> - When making the call to request_token [4] (server-to-server), you can pass >> &oauth_callback=[url here] >> - The response from request_token will contain oauth_callback_confirmed=true >> to confirm we received it. >> - The user will be sent to twitter.com as usual >> - When the user is finished they will be redirected to the URL provided in >> the first step along with a new parameter, oauth_verifier [1] >> - The call to access_token [5] to exchange the request token for an access >> token MUST contain the oauth_verifier parameter as sent in the redirect. >> - If you want to use your pre-configured callback, then do not include a >> oauth_callback parameter. >> - If you want to force the PIN-based solution, send oauth_callback=oob with >> your request to oauth/authenticate >> >> Additionally, as a couple developers have already noticed, we deployed the >> code that implemented PINs for desktop apps originally mentioned by Matt. >> Please review the linked documentation [2] and discussion [5] and let us >> know what questions you have. >> >> If you find that your browser-based OAuth application is returning a PIN as >> if it were a desktop app, then remove the oauth_callback=oob parameter from >> your signature, if it exists. >> >> 1.http://blog.luckycal.com/?p=121 >> 2.http://apiwiki.twitter.com/Authentication >> 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_t... >> 4.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-access_token >> 5.http://groups.google.com/group/twitter-development-talk/browse_frm/th... >> >> Thanks, >> Doug >
