Yup, I know, that's what I'm asking. Why not link to and tell people to use 1.0a (or the IETF draft) rather than 1.0?
For the record I checked all the other code examples and none of them support oauth_verifier (some do send oauth_callback with the first request), unless I'm missing something. http://github.com/moomerman/twitter_oauth is the only one that's up to date. -M On Jan 22, 2010, at 1:18 PM, ryan alford wrote: > If you look at the very top of the 1.0 spec, you will see a yellow box... > > "This specification was obsoleted by OAuth Core 1.0 Revision A on June 24th, > 2009 to address a session fixation attack. The OAuth Core 1.0 Revision A > specification is being obsoleted by the proposed IETF draft > draft-hammer-oauth. The draft is currently pending IESG approval before > publication as an RFC. > > Implementers should use draft-hammer-oauth instead of this specification." > > > Here is the link to the 1.0a spec. > http://oauth.net/core/1.0a/ > > Ryan > > On Fri, Jan 22, 2010 at 10:29 AM, Marc Hedlund <marcprecip...@gmail.com> > wrote: > I'm confused about the OAuth docs linked to from http://apiwiki.twitter.com/ > -- especially these: > > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_token > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-access_token > > Both of these link to the OAuth 1.0 spec for a list of required > parameters. Shouldn't they link to the 1.0a spec instead? > > I came to the docs remembering the news story from last April about > OAuth and session fixation vulnerabilities: > > http://oauth.net/advisories/2009-1/ > http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/ > http://www.readwriteweb.com/archives/how_the_oauth_security_battle_was_won_open_web_sty.php > > And how it affected Twitter: > > http://blog.twitter.com/2009/04/whats-deal-with-oauth.html > http://news.cnet.com/8301-13577_3-10225103-36.html > > But if you look at the API docs today, it's like none of this > happened. I can't find 1.0a documented anywhere, and all but one of > the code examples the docs link to continue to use the 1.0 token flow > (only http://github.com/moomerman/twitter_oauth appears to get it > right of the ones I checked -- > http://github.com/henriklied/django-twitter-oauth > and http://github.com/tav/tweetapp don't, for instance). > http://apiwiki.twitter.com/OAuth+Example+-+Ruby isn't publicly > visible. Session fixation isn't mentioned on the "Security Best > Practices" page (http://apiwiki.twitter.com/Security-Best-Practices). > 1.0 vs 1.0a isn't in the OAuth FAQ (http://apiwiki.twitter.com/OAuth- > FAQ) or the main FAQ. > > (I do see > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/472500cfe9e7cdb9 > and of course all the discussion of OAuth and the PIN problems for > mobile apps.) > > Shouldn't the documentation point people towards the current spec, and > show examples that implement it? Or is there some reason people are > being pointed to 1.0? > > I'm asking because Tornado (http://www.tornadoweb.org/) provides a > Twitter OAuth mixin in its auth module (http://github.com/facebook/ > tornado/blob/master/tornado/auth.py) which uses the 1.0 token flow (as > do all of the OAuth mixins in Tornado). Google OAuth implements 1.0a, > and shows the user a security warning if the 1.0 flow is used, but > Tornado makes this hard to implement using their auth module. I'm > working on a patch to send them and want to know whether the Twitter > OAuth mixin should be upgraded for 1.0a or if there's some reason it > shouldn't. > > Thanks. (I'll stay on this list long enough to hear the discussion > but will probably bail out after that, since it's a high-volume list > and my interest is just in making the patch right.) > > -Marc >
