You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by Chris Jackson <cj...@ghsinc.com> on 2002/12/18 23:08:28 UTC
SecureXmlRpcTransport?
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?
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?
We've got dead lines, so we will start down that road, but thought it
would be nice if we ended up with code of use to others and didn't
duplicate someone else efforts or step on someoneelse's code.
Chris J.
GHS Data Mgt.
"Critical thinking does not work in an
environment of ignorance of critical facts."
- George C. Jeffrey
Re: SecureXmlRpcTransport?
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I am also involved in this refactoring and I think your contribution
would be appreciated. Specifically, it could fill a need for a
lightweight SSL transport to go with the lightweight cleartext
transport. The Jakarta Commons HttpClient transparently handles SSL,
and I will contribute a transport based on that PSN. ;) Some end of year
projects have taken me out of circulation for the past few weeks.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
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.
>
Re: SecureXmlRpcTransport?
Posted by Michael Isbell <mi...@advancient.com>.
Chris Jackson wrote:
>We have a functioning implementation of SecureXmlRpcTransport and
>DefaultXmlRpcTransportFactory with a very permissive X509TrustManager
>(no cert checking or hostname verification)
>
>
>
well done! would've saved me a week or two of programming as I learned
the code, read O'Reilly's security code and hand-baked my own solution!
Re: SecureXmlRpcTransport?
Posted by Michael Isbell <mi...@advancient.com>.
Chris Jackson wrote:
>We have a functioning implementation of SecureXmlRpcTransport and
>DefaultXmlRpcTransportFactory with a very permissive X509TrustManager
>(no cert checking or hostname verification)
>
>
>
well done! would've saved me a week or two of programming as I learned
the code, read O'Reilly's security code and hand-baked my own solution!
Re: SecureXmlRpcTransport?
Posted by Chris Jackson <cj...@ghsinc.com>.
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
compile.
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) {
e.printStackTrace();
}
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.
>
>
>
Re: SecureXmlRpcTransport?
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I am also involved in this refactoring and I think your contribution
would be appreciated. Specifically, it could fill a need for a
lightweight SSL transport to go with the lightweight cleartext
transport. The Jakarta Commons HttpClient transparently handles SSL,
and I will contribute a transport based on that PSN. ;) Some end of year
projects have taken me out of circulation for the past few weeks.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
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.
>
Re: SecureXmlRpcTransport?
Posted by Chris Jackson <cj...@ghsinc.com>.
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
compile.
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) {
e.printStackTrace();
}
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.
>
>
>
Re: SecureXmlRpcTransport?
Posted by Andrew Evers <ae...@redwood.nl>.
> 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.
Re: SecureXmlRpcTransport?
Posted by Andrew Evers <ae...@redwood.nl>.
> 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.