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) | 2010-07-16 | Approve on 2010-07-19 | |
| Gary Poster (community) | 2010-07-16 | Approve on 2010-07-19 | |
| Martin Pool (community) | 2010-07-16 | Approve on 2010-07-16 | |
|
Review via email:
|
|||
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.)
| Leonard Richardson (leonardr) wrote : | # |
I did test this branch interactively against my dev instance, using a web browser and wget.
I'd like salgado to take a quick look from a security standpoint and then I'll land it.
| Gary Poster (gary) wrote : | # |
Looks good to me.
I don't see how this changes the security profile, so I'm +1 on landing it. I'm certainly happy to get another review, though.
| Guilherme Salgado (salgado) wrote : | # |
<salgado> leonardr, it looks fine to me, but an unrelated thing is that it is not clear to me that consumers.

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.