internal xmlrpc service requires impersonation to be handled per-method rather than systematically

[Michael Hudson-Doyle]

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.

[Michael Hudson-Doyle (mwhudson)]

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.