r.d., I'll follow up with you on that in the other thread.
T On Mon, May 24, 2010 at 7:50 AM, ramy <ramy.daghst...@gmail.com> wrote: > sorry to jump in like this, but i've followed the authentication steps > and the server never responds, i started a thread earlier this week > detailing my problems here: > > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a7e0f3968c6eed74 > > I've tested the encoding and signing process against the test strings > provided in the docs, and everything checks out, The authorization > header IS in fact being sent but the server never responds. > > tips? > > r.d. > > On May 24, 10:24 am, Taylor Singletary <taylorsinglet...@twitter.com> > wrote: > > Hi Tony, > > > > Yes, the documentation is yet to be written, but will be coming as soon > as I > > can finish it up. > > > > I'll be happy to help you through it until then though. > > > > To ready your application for out-of-band OAuth, first configure your > > application on dev.twitter.com/apps to be a "Client" mode app (no > callback > > URL pre-supplied). > > > > For the majority of the documentation you find ahttp:// > dev.twitter.com/pages/auth-- your process is going to be exactly the > > same. > > > > - On the request token step, instead of providing a dynamic > oauth_callback > > parameter, you will be supplying the string "oob" -- everything else > about > > the request is the same. > > - After getting your request token, you send the user to the > authorization > > URL just as normal. > > - When the user provides their login information, instead of being > > redirected to your application, they are presented with a page containing > a > > short set of characters that they are asked to enter into your > application > > - You provide a user interface in your application that collects the > PIN > > code (also known as the "oauth_verifier"). Then you build an access token > > exchange request, exactly like the standard access token request, except > you > > provide the oauth_verifier you retrieved from the user. In standard OAuth > > flows, the oauth_verifier would have been given to you in your > > oauth_callback. > > > > Everything else about this flow is exactly the same. > > > > The only gotcha here is that a single application has to choose to either > be > > an "out of band" / "desktop client" application OR a dynamic web > application > > with dynamic callback URLs. > > > > Taylor > > > > Taylor Singletary > > Developer Advocate, Twitterhttp://twitter.com/episod > > > > On Mon, May 24, 2010 at 6:59 AM, Tonyw <tonywarri...@gmail.com> wrote: > > > I'm thinking (or was) of using the new oauth in a c++ app. But the > > > docs are vague to say the least. > > > > > Given that this is actually missing - > > > > >http://dev.twitter.com/pages/auth#oob > > > > > is there any hope!? > > > > > ;) > > > > > tony >
