launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02743
Re: using PermissiveSecurityPolicy when serving private xmlrpc requests
Bjorn Tillenius wrote:
> On Wed, Feb 24, 2010 at 01:26:59PM +1300, Michael Hudson wrote:
>> Bjorn Tillenius wrote:
>>> On Tue, Feb 23, 2010 at 05:56:47PM +1300, Michael Hudson wrote:
>>>> 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).
>>> Can you give a list of all the methods that the private XML-RPC server
>>> currently implements?
>
> So, I thought a bit more about this. I think it makes sense for the
> private XML-RPC server to work in a similar manner as scripts work.
> However, I do want us to get rid of the PermissiveSecurityPolicy, since
> it's a bit too permissive. Instead, I want the scrips (and private
> XML-RPC server) to set up an interaction using a special "system user"
> principal, or a principal more specific to the current task. The latter
> is better, but the former might be enough, at least to start with. The
> normal security policy can now look for this special principal, and give
> appropiate access.
This all sounds reasonable to me. Being a bit more sophisticated about
principals for the private XML-RPC server also sounds nice because there
are some methods (translatePath, createBranch) which act on behalf of a
Launchpad user and currently use the test helpers 'login_person' and
'logout', which is a bit ick.
Cheers,
mwh
Follow ups
References