Yes, this is correct. To perform this key exchange, a consumer key (API key) with this feature enabled is all that's required to be stored in your open source app.
Some other interesting facts: - A parent application can only spawn 1 version of itself for a user. If the user repeats the flow, their pre-existing app will be returned. - xAuth will not be granted to these keys. For clarity here on why xAuth isn't allowed: having keys out in the public, or easily accessible to the public, that can perform xAuth is absolutely a bad idea. Anyone with a collection of logins and passwords can batch convert them to access tokens, giving themselves access to a member's account regardless of the login and password changing. (This is the other side of the coin.. on one side of the coin you have the advantage that OAuth applications keep working even if the user changes their password (YAY!) and then you have on the side of the coin that OAuth applications keep working even if the user changes their password and they have no idea that they've granted an OAuth access token without their explicit permission (BOO!) ) - Users with suspended accounts cannot create these kind of applications - Applications with suspended status cannot have users create new applications - The result of this process is everything an app needs to function for the user: a consumer key, a consumer secret, an access token, and a access token secret. - We're only allowing open source applications for now. We may consider other use cases in the future. - The user gets an application in this deal. That's actually a big thing. It's not just a row in a database. Addressing a few other points: This process puts the power of the application completely in the hands of the user. Because of this, it's best suited for applications that cater to users with a more advanced understanding of what they're doing. Of course, it's not terribly difficult to perform all the necessary actions, but this feature was not built with a "super-awesome seamless user experience" in mind. It also, naturally, by requiring the user to agree to the API terms of service, comes with other baggage for your users. There are many advantages to this approach from a management perspective for us. It also better shields developers from the actions that can be taken by malicious users, should they reveal their own consumer secrets in their open source apps. We don't want you to do that, that's why we're offering this option. Some users might screw up the copy & paste step. Code defensively. Scrub the input. Verify that it's in the format you think it should be before assuming it's correct. After you parse the tokens, do a verify_credentials API requests or something similar to test if it works. If it doesn't work, try sending the user through the process again (they'll get the same result as the first time). Taylor On Sat, Jun 12, 2010 at 7:12 AM, Cameron Kaiser <[email protected]>wrote: > > @taylor > > So key exchange is done based on consumer key only.(No need to verify the > > signature?.Makes sense as this is distributed )So any abuse by the end > user > > will only lead to the ban of child app ? (assuming the final auth > requests > > are signed by the generated secrets (chid app secret and user secret > only) ) > > IDSOWFT, but that is the way I understand it. > > -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > [email protected] > -- Roger Waters, public health officer: "Careful with that pox, Eugene!" > ------ >
