Merge lp:~leonardr/launchpad/true-anonymous-access into lp:launchpad/db-devel
Status: | Merged |
---|---|
Merged at revision: | 9552 |
Proposed branch: | lp:~leonardr/launchpad/true-anonymous-access |
Merge into: | lp:launchpad/db-devel |
Diff against target: |
141 lines (+88/-9) 2 files modified
lib/canonical/launchpad/pagetests/webservice/xx-service.txt (+70/-2) lib/canonical/launchpad/webapp/servers.py (+18/-7) |
To merge this branch: | bzr merge lp:~leonardr/launchpad/true-anonymous-access |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Guilherme Salgado (community) | Approve | ||
Gary Poster (community) | Approve | ||
Martin Pool (community) | Approve | ||
Review via email: mp+30088@code.launchpad.net |
Description of the change
This branch makes it possible to get read-only access to the Launchpad web service (the actual one, at api.launchpad.net, not the one for Ajax apps) using an OAuth-ignorant client like wget or a web browser. Internally, the User-Agent string is treated as the "consumer key", and anonymous read-only access is allowed on the same terms as we currently allow OAuth requests signed with a token that is the empty string.
Although I'm confident there are none, I would like the reviewer to take a close look for possible security problems such as privilege escalation attacks within getPrincipal().
My real problem with this branch is that there is no longer a real failure mode for web service implementations. If you screw up your OAuth implementation, or you try to authenticate with Basic Auth and your Launchpad username/password, you will no longer get an exception. You'll get anonymous read-only access. But, I don't think it's worth making a big deal of this, trying to get failure modes back by checking for incomplete OAuth implementations, etc. (At most, I might check for an Authorization header that's not a valid OAuth Authorization header.)
That looks good to me, though I'm not very expert on Launchpad's security internals.
> If you screw up your OAuth implementation, or you try to authenticate with Basic Auth and your Launchpad username/password, you will no longer get an exception. You'll get anonymous read-only access. But, I don't think it's worth making a big deal of this, trying to get failure modes back by checking for incomplete OAuth implementations, etc. (At most, I might check for an Authorization header that's not a valid OAuth Authorization header.)
I think it would be reasonable to handle that as a separate bug if and when anyone actually files it. If the OAuth header is corrupt as opposed to just absent I think we should still give an error.
Did you interactively test that against your dev instance?
Thanks very much, this is a nice step forward for API usability.