It worked for a one time oauth conversion for about 3000 accounts (i ran a batch job across five processes and think it took an hour or so to finish)-- however, that was back in may. the script was also written pre oauth 1.0a, so there's no oauth_verifier. I'm not sure if that's required now.
On Feb 13, 11:41 am, Dewald Pretorius <[email protected]> wrote: > Mmmm.... it looks as if you're scraping the pre-login Allow/Deny page. > That might just get your IP address blackholed. > > On Feb 13, 11:44 am, jon <[email protected]> wrote: > > > > > FYI, if anyone wants to get an to do a poor man's version of xAuth, > > I'd written a script a few months ago to exchange credentials: > > >http://gist.github.com/108144 > > >http://groups.google.com/group/twitter-development-talk/browse_thread... > > > - Jon > > > On Feb 12, 8:52 pm, Norio Nomura <[email protected]> wrote: > > > > Hi, > > > > I tested xAuth with below > > > codes,http://github.com/norio-nomura/ntlniph/tree/xAuth > > > and succeeded. > > > > I want to know about xAuth's current status and roadmap. > > > > Thanks, > > > > -- > > > Norio Nomura > > > > On 2月12日, 午後12:18, Raffi Krikorian <[email protected]> wrote: > > > > > hi all. > > > > > this is a long overdue e-mail, but i wanted to tease out some of the > > > > directions that Twitter is going with OAuth. i want to touch upon four > > > > topics: delegation, OAuth WRAP/2.0, username/password OAuth token > > > > exchange, > > > > and basic authentication deprecation. > > > > > *DELEGATION - OAuth Echo* > > > > > twitter users love posting media on third-party sites, and delegation in > > > > identity verification is one of the major hurdles for an OAuth-enabled > > > > twitter client to succeed. i started a series of blog posts around the > > > > following problem: > > > > > You're an OAuth enabled Twitter client, and you've already authorized > > > > your > > > > > > user. Your user wants to use a media providing service like TwitPic. > > > > > TwitPic, currently, asks for the username and password of your user > > > > > so it > > > > > can store the photo on behalf of the Twitter user. You don't have > > > > > that > > > > > username and password, so how do you give the ability to TwitPic to > > > > > verify > > > > > the identity of your user? > > > > > check out the proposal for what we're calling "OAuth Echo" > > > > athttp://mehack.com/OAuth-echo-delegation-in-identity-verificatio. > > > > please > > > > feel free to comment there, or on the twitter development talk mailing > > > > list<http://groups.google.com/group/twitter-development-talk>(or, even > > > > just reach out to me directly). i think this experiment in > > > > engaging the community around designing this security/identity workflow > > > > has > > > > been definitely a success, and i feel we're rapidly converging on a > > > > solution > > > > for identity verification delegation. in parallel, we're going to > > > > start the > > > > process to engage our media providers in the conversation as well, and > > > > we're > > > > hopeful we can move this forward quickly. > > > > > *OAUTH WRAP/2.0* > > > > > OAuth is evolving, and we at Twitter are keeping up with it. that being > > > > said, we're keeping our eyes on OAuth WRAP and OAuth > > > > 2.0<http://wiki.oauth.net/OAuth-WRAP>. > > > > we like a lot about it: > > > > > - it requires the use of SSL; > > > > - there is no custom signing mechanism -- you simply pass us a > > > > token, and > > > > that token is secured by SSL; and > > > > - it formalizes a bunch of "profiles" that we've been actively > > > > thinking > > > > about (e.g. a username/password exchange) > > > > > in general, we really like WRAP/2.0 because it's just *so* easy to > > > > implement > > > > from the client side. there are no longer questions around creating the > > > > proper signature base string, etc. we're sure that developers will > > > > like it > > > > as well. we've started work on an internal implementation of OAuth > > > > WRAP and > > > > we envision that we'll simultaneously support both OAuth 1.0a and > > > > WRAP/2.0 > > > > for a while. our hope is to get WRAP out the door soon (and before we > > > > finally deprecate basic authentication). > > > > > *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth* > > > > > @rsarver and @noradio announced that we are going to support a mechanism > > > > where a username and a password can be directly exchanged for an OAuth > > > > token > > > > and secret -- we're calling this xAuth. if you've been watching the > > > > mailing > > > > list, Seesmic Look <http://seesmic.com/look> has been a beta partner in > > > > testing xAuth exchange (and @abraham has already detailed how it > > > > works<http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser...>). > > > > > because we're moving everybody off basic authentication, we originally > > > > envisioned this as a mechanism for developers to exchange all the > > > > username > > > > and passwords they have in their databases for OAuth tokens en masse. > > > > that's still one of our use cases. another use case is around > > > > environments > > > > where software can't bring up a web browser (e.g. set top boxes, game > > > > consoles, embedded devices). we want to support those as well. > > > > > you're going to have to apply to get access to this exchange mechanism > > > > (by > > > > sending e-mail to [email protected]), but, in general, all applications > > > > except > > > > web applications will get access. we feel that the xAuth exchange > > > > allows > > > > for the best mix of security and user experience for desktop and > > > > possibly > > > > mobile applications. web applications will simply have to use OAuth as > > > > it > > > > was designed, and send their users through the web flow. > > > > > *BASIC AUTHENTICATION DEPRECATION* > > > > > yup - it's still happening. we're targeting June 2010. everybody, > > > > including legacy applications, will have to move over. > > > > > for those who are building new applications, use OAuth. save yourself > > > > the > > > > transition time later, and start thinking about it now. for those who > > > > have > > > > applications already out there, it would be really beneficial to start > > > > thinking about a migration path right now and we're here to help. if > > > > you > > > > need it, please feel free to reach out to us and we'll help you figure > > > > out > > > > what you need to do. > > > > > to help entice you over, as you know: > > > > > - we have increased rate limits on api.twitter.com to those who are > > > > using > > > > OAuth (350 calls to the REST API per hour -- and increasing towards > > > > 1500/hour); and > > > > - (as some of you are painfully aware) you can only set a source > > > > parameter with OAuth calls to status/update. > > > > > we know some of you think there are hurdles in places to converting > > > > over to > > > > OAuth -- suffice it to say, we're actively trying to address them. some > > > > potential hurdles are mentioned in this e-mail, and if you think there > > > > are > > > > more then please feel free to reach out to us. again, we really want to > > > > make this switch-over easy for everybody. > > > > > thanks! and, as always - feel free to reach out to us anytime here, or > > > > to > > > > @twitterapi. > > > > > -- > > > > Raffi Krikorian > > > > Twitter Platform Teamhttp://twitter.com/raffi
