launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02690
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