| 2008-02-28 02:32:53 |
Michael Hudson-Doyle |
bug |
|
|
added bug |
| 2008-02-28 15:52:49 |
Diogo Matsubara |
description |
The thread "webapp security vs the private xmlrpc server" on the launchpad mailing list talks about how to implement this. |
The thread "webapp security vs the private xmlrpc server" <https://lists.ubuntu.com/mailman/private/launchpad/2008-February/025282.html> talks about how to implement this. |
|
| 2008-02-28 15:53:06 |
Diogo Matsubara |
launchpad: status |
New |
Confirmed |
|
| 2009-10-09 00:08:03 |
Curtis Hovey |
tags |
infrastructure |
infrastructure tech-debt |
|
| 2009-11-06 04:53:43 |
Curtis Hovey |
launchpad-foundations: status |
Confirmed |
Triaged |
|
| 2009-11-06 04:53:47 |
Curtis Hovey |
launchpad-foundations: importance |
Undecided |
Low |
|
| 2011-05-30 03:05:14 |
Robert Collins |
visibility |
private |
public |
|
| 2011-05-30 03:05:16 |
Robert Collins |
removed subscriber Launchpad Bug Contacts |
|
|
|
| 2011-05-30 03:25:39 |
Robert Collins |
summary |
implement endpoint specific authentication for the private xml-rpc server |
internal xmlrpc service requires impersonation to be handled per-method rather than systematically |
|
| 2011-05-30 03:25:51 |
Robert Collins |
description |
The thread "webapp security vs the private xmlrpc server" <https://lists.ubuntu.com/mailman/private/launchpad/2008-February/025282.html> talks about how to implement this. |
What this was about at the time was wanting the implementation of private xml-rpc methods (which are unauthenticated) to be able to access methods that were restricted to members of ~vcs-imports (kind of a naff implementation of what is now feature flags) without using removeSecurityProxy all over the place. So the idea was that we would map xml-rpc endpoints (such as /codeimportscheduler) to particular principals in PrivateXMLRPCPublication.getPrincipal.
Obviously, the new code import system got completed without this ever being done, but there is perhaps a related need to handle impersonation in xml-rpc methods better. Methods such as createBranch clearly act on behalf of a particular user, and this is implemented in a rather crude way that expects the first argument to be a launchpad user id and basically stomps over the interaction (and request!) that the zope publication machinery has set up (although at least it no longer uses test helpers to do so). We could instead do this by (say) reading a hypothetical X-Act-As-Launchpad-Id: header in PrivateXMLRPCPublication.getPrincipal, and this would probably be cleaner. On the one hand, what we have now works and has worked for many years, on the other, this kind of thing will crop up all over the place if we move to a service architecture, and it may pay to establish a convention for requesting impersonation that is outside the wire protocol used to transmit requests. |
|
