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 <dpr...@gmail.com> 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 <jonhoff...@gmail.com> 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 <norio.nom...@gmail.com> 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 <ra...@twitter.com> 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 a...@twitter.com), 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

Reply via email to