Regarding the user being able to set the source tag themselves: they will be able to -- the application created for the user is totally their application. They can change the name of the application to anything they want (within the same rules as any application name on the platform).
The WordPress use case has been thought of and we're still considering an additional delivery mechanism than just cut and paste. However, it would have to involve a callback and that would be best served with some form of verifiable identity (that you're in fact receiving a callback from Twitter and that the callback URL wasn't manipulated or pointing to an unwanted location). In that case, we'd likely have to setup some kind of public certificate exchange. Taylor On Sat, Jun 12, 2010 at 1:31 AM, Zac Bowling <zbowl...@gmail.com> wrote: > Interesting idea. > > I didn't think it was to hard if you had user that was fiddling with your > source to just have him generate his own keys and while I just compile my > keys into my official binary builds but I guess for scripting based clients, > this makes sense. I guess you get the attribution and client tracking on the > Twitter side as well. > > Sometimes though this is not ideal, like a wordpress twitter plugin I use. > I forced it to use my own keys because I want it to say "myblogsite.com" > in the attribution link and not "UberWordPressTwitterPlugin" or whatever. > > If you can make it where the user can optionally edit the source > attribution tag and link when they set it up the clone, then I would > probably direct my users to use this approach over manually creating their > own original consumer and secret. > > Zac Bowling > @zbowling > > > > On Jun 11, 2010, at 3:56 PM, Taylor Singletary 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=abcdefghijklmnopqrstuvwxyz > 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=542212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOzzzzEwxOBWPPREd55dKx7AAaI8NfpK7xnibv4Yls > > 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, Twitter > http://twitter.com/episod > > >
