Hi Everyone, We're waiting on a few minor bug fixes to be in place before rolling this out to a wider audience. I'll post a new message when things are good to go and we're ready to accept applications into the feature.
Taylor On Sun, Jun 20, 2010 at 1:30 AM, nov <mat...@gmail.com> wrote: > Hi, Twitter API team > > Is this feature already released? > If so, how can we register key_exchange enabled consumers? > > On 6月12日, 午前7:56, Taylor Singletary <taylorsinglet...@twitter.com> > wrote: > > Hi Developers, > > > > As has been discussed on the list recently, OAuth and Open Source > > applications are a difficult combination because token secrets shouldn't > be > > embedded in widely distributed code. > > > > We're pleased to announce that we've devised a solution to this problem. > > > > Next week, we plan to release a new extension to the Twitter API that > will > > allow Open Source applications to obtain OAuth consumer keys and secrets > for > > their users, without having to distribute an application secret. > > > > Approved Open Source client applications will have an easy to implement > > ability, through dev.twitter.com, to generate new client tokens & > secrets to > > be used specifically for each new instance of the application. > > > > While completing the process does require the end-user to complete a few > > extra operations, we think this is a good compromise. > > > > The source tag on tweets published by the child applications generated > with > > this approach will be a variation on the originating application's name. > For > > examples, if the name of the parent application was "AdventureTweet" and > the > > user's screen name was @zork, then the child application's name would be > > "AdventureTweet (zork)". > > > > The work flow for these applications will be something like this: > > > > 1. You store your API Consumer Key in your application distribution > (but > > never your secret!). > > 2. A user downloads/installs/checks out your open source application > and > > runs it for the first time > > 3. Your application builds a URL to our key exchange endpoint, using > your > > consumer key. > > Example: > http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi... > > 4. You send the user to that URL in whatever way makes sense in your > > environment. > > 5. That user will have to login using their Twitter credentials (if > they > > aren't already), and then approve your application's request to replicate > > itself on the user's behalf. > > 6. The approval will require that the user agrees to our terms of > service, > > as this process results in them having control of their own application > > 7. The user is presented with a string that they are asked to paste > into > > your application. The string will contain ah API key and secret, in > addition > > to an access token and token secret for the member: everything that's > needed > > to get the user up and running in your application. > > 8. The user pastes the string into your application, which then > consumes > > and stores it to begin performing API calls using OAuth. > > > > The string containing the keys will be x-www-form-urlencoded. To keep the > > string brief, it will contain abbreviated key names. > > > > An example: > > > ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=5 > 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55 > dKx7AAaI8NfpK7xnibv4Yls > > > > Where: "ck" - consumer key, "cs" - consumer secret, "at" - access token, > > "ats" - access token secret > > > > This kind of key requisition service is new to the Twitter ecosystem, and > > we're going to be closely monitoring it for abuse. Once we announce its > > availability, we'll begin taking requests for Open Source applications > that > > would like to offer the feature in their application. > > > > We're excited to offer this solution to the open source community. Thanks > > everyone! > > > > Taylor Singletary > > Developer Advocate, Twitterhttp://twitter.com/episod >
