xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Jackson <cjack...@ghsinc.com>
Subject Re: SecureXmlRpcTransport?
Date Fri, 20 Dec 2002 21:19:58 GMT
We have a functioning implementation of SecureXmlRpcTransport and
DefaultXmlRpcTransportFactory with a very permissive X509TrustManager
(no cert checking or hostname verification) We'll tighten that up soon,
but our current dilemma has to do with JSSE support - our current code
sets the "java.protocol.handler.pkgs" to
"com.sun.net.ssl.internal.www.protocol" to support Tomcat's use of the
old JSSE api - is this a problem with anyone? 1.4.x depreciates the
com.sun.net.ssl api in favor of the javax.net.ssl and complains on
We are also not sure of the best way/where/when to set this system
property because it globally overrides other protocol handlers. Don't
know if this steps on anyone's code. It has to be set before creating
URL objects (AFAIK) so we would need to do this setup before creating
URL objects for XmlRpcClient contructors are called. I'd like to do
something like:

URL url = new URL("https://server/path");
XmlRpcTransportFactory factory = new DefaultXmlRpcTransportFactory();
XmlRpcRequest request = new XmlRpcRequest("method.call", new Vector());
XmlRpcClient client = new XmlRpcClient(url, factory);

String result = null;
try {
     result = (String)client.execute(request);
}catch(Exception e) {

but adding a SecurityTool() type of call before that is possible.

On Wed, 2002-12-18 at 23:38, Andrew Evers wrote:
> > Myself and another coder here are looking to implement some secure
> > xml-rpc clients and services, but it looks like the current code base
> > is very much in flux with the recent refactoring/addition of the
> > XmlRpcTransport stuff. My question to the list is should we take a
> > crack at implementing SecureXmlRpcTransport or does someone have
> > something in the works already?
> Well, I'm responsible for that particular refactoring, as far as I
> know noone is working on the area you mention, so by all means have
> a go.
> I think there were a couple of posts with proposed changes to the
> secure behaviour on this list about 2 weeks ago.
> If you want to start work on a SecureXmlRpcTransport and post the
> extra classes to the list, then I can review them and commit them
> (unless there are major objections). Alternatively, create a ticket
> in bugzilla and attach them to that:
> http://nagoya.apache.org/bugzilla/enter_bug.cgi
> > We are assuming that the secure.SecureXmlRpcClient will be depreciated
> > by XmlRpcClient using a transport factory that looks at the URL
> > protocol to decide whether to do DefaultXmlRpcClient or
> > SecureXmlRpcTransport (or something else), are we off the mark?
> Probably ;), in that I haven't really thought that far ahead.
> If you develop a secure.SecureXmlRpcTransport with constructors:
> + URL (obvious, but check for https://),
> + String (as URL but for convenience) and,
> + Hashtable/Properties (think client certs and the like).
> Then we can plug this into whatever generic mechanism we use for
> transport creation, and leave things open enough to allow programmers
> to instatiate a custom transport or extend the transport to develop
> their own.
> Andrew.

View raw message