← Back to team overview

launchpad-dev team mailing list archive

using PermissiveSecurityPolicy when serving private xmlrpc requests

 

Hi there.

Today's hacking has involved working on methods implemented by the
private xml-rpc server.  If you've done this before, you'll know that it
can be a bit annoying as calls to this server are not authenticated, so
you end up having to weaken the security declarations a whole lot or use
removeSecurityProxy liberally, neither of which feels very nice (I have
complained about this before, I think).

Really, given the role the internal xml-rpc has in our system, the
PermissiveSecurityPolicy (as used by 'zopeless' scripts) is much more
appropriate for these requests.  Is this easy to achieve?  I stared into
the zope vortex for a bit, and it seems like it's almost but not quite
easy: basically, we'd want to be able to influence the class of the
interaction the call to newInteraction in
canonical.launchpad.webapp.publication.LaunchpadBrowserPublication.beforeTraversal
instantiates and that would be that -- but newInteraction always reads a
global variable to figure out which class to instantiate.  So a
copy-paste-hack of newInteraction would probably be required.

Does anyone have any thoughts on the matter?

Cheers,
mwh




Follow ups