OAuth/10a
This page has been created to create documentation on the oauth problems/upgrades in June 2010
Keep these things straight in your head:
- There is a difference between OAuth protocol version 1.0 and 1.0a
- There is a ruby oauth gem (versions 0.3.4, 0.3.6 and 0.4.0 are of interest) used by both the rails_port and any ruby scripts
- There is a rails oauth-plugin (version "svn" (from around Feb 11 2009) and 0.3.14 are of interest) used by only the rails_port. This has the oauth gem as a dependency
Contents |
What happened
In commit 41a12333, TomH moved the rails_port from having a copy of oauth-plugin (version "svn") to using the oauth-plugin as a gem. This had the side effect of upgrading oauth-plugin from "svn" to 0.3.14
At this point some OAuth apps (mapzen, mapzen poi collector, potlatch2) continued to work, but others stopped working and triggered HTTP 401 responses from the API. All clients could still work fine with api06.dev.openstreetmap.org
What went wrong
The upgrade to oauth-plugin also requires changes to the models/controllers, as outlined at http://github.com/pelle/oauth-plugin (section "Upgrading from OAuth 1.0 to OAuth 1.0a"). Without these changes we ended up with a hybrid/broken implementation of OAuth, where 1.0 clients would work and 1.0a clients would not work. This is in contrast to the previous version, running on api06.dev, where both 1.0 and 1.0a clients would work fine, with the 1.0a clients successfully falling back to 1.0
OAuth 1.0 clients:
- potlatch2
- mapzen?
- mapzen poi collector
- ruby scripts running with oauth gem 0.3.4 or earlier
OAuth 1.0a clients
- ruby scripts running with oauth gem 0.3.6 or 0.4.0
- new versions of the signpost library
- new version of JOSM
It's worth noting that the production servers and dev are running different oauth gem versions (was 0.3.6 and 0.4.0 at the time of writing). Tests show this makes no difference to the situation, it's only oauth-plugin that matters.
OAuth 1.0 vs 1.0a
OAuth protocol 1.0a addresses a session fixation attack during the request token -> access token interface. But it's not entirely clear if this is a problem for us, since we store callback urls during application registration, not during token exchange. It might turn out that, so long as we do the correct upgrades, 1.0 clients can still work without change.
Plan
- Revert 41a12333 and deploy (done)
- branch off an oauth-upgrading branch (next)
- make the relevant changes for upgrading to oauth-plugin 0.3.14
- enable 1.0 compatibility mode? and deploy
- check / upgrade old 1.0-era osm client apps?
- disable 1.0 compatibiity mode?
Other Todos
- Create tests to cover all these issues
The potlatch2 distraction
It's easy to waste a number of hours using potlatch2 to test against the API, for one very good (but perhaps unclear) reason. I used the potlatch2.html page, served from localhost:3333 in order to test accessing the dev server, a local test server and the live server. But potlatch2 uses flash cookies to store the oauth tokens, and the scope of the cookie is the instance of the .swf. Since this was always localhost:3333/potlatch2.swf, it would keep trying the same token on a different server while flicking between tabs.
It's possible to use the flash cookie manager at http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html to remove the cookies, but it's probably best to use the ruby scripts from OAuth/Examples to test instead since they don't accidentally store any state.
