> I've used the default support available by these classes. Thus it will > run on a potentially public TCP/IP port. As the application backend > allows, among other things, saving files to the local filesystem, this > would be a clear security hole in the wild. Restricting it to > localhost would be a start, but not sufficient for multi-user systems.
This might not be the answer you want, but I'd personally ditch xmlrpc and switch to something like pyro or even corba and implement a "real" authentication theme. They are easy to use, provide a full OO-style interface and are even faster than xmlrpc. Part of the problems you're facing stem from the stateless nature of xmlrpc (and soap, for that matter). That allows everybody to access the API without prior authentication. It requires some effort to implement a authentication/authorization scheme over xmlrpc. What usually is done in xmlrpc in similar situations like yours is that there is a authenticate(user, password) function that will return a handle on success that has to be passed to all subsequent calls to other functions. All this because the handle can't be associated with each and every xmlrpc request (in soap that can be done, but its undstandarized.) With corba/pyro, authenticate would return an object that implicitely has all the state needed - nameley who created the connection - and then you don't have to bother about that anymore. Switching to pyro shouldn't be much more than a few lines of code, more or less only subclassing your server from Pyro.core.ObjBase instead of SimpleXMLRPCServer. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
