Jason van Zyl wrote: > On Fri, 2002-04-26 at 12:15, William Lee wrote: > >>Jason van Zyl wrote: >> >>>On Thu, 2002-04-25 at 16:29, William Lee wrote: >>> >>> >>>>Does the SecureXmlRpcClient code actually work in 1.1? From the service >>>>it doesn't look like it would. It's essentially using the underlying >>>>XmlRpcClient code and eventually involke the a URLConnection. In fact, >>>>I got the error when it tries to construct the URL object with the >>>>string "https://blahblah:8888/RPC2"; and complain about https is not a >>>>valid protocol (???). Does anyone know what's going on there? >>> >>> >>>What context are you using the security in. It works fine, been using it >>>for about a year with no problems. >>> >>> >> >>First of all, do you need to setup the SecurityTool before you do it? >>I'm essentially doing: > > > Yes, I have only tested this thoroughly under tomcat3 and I initially > made the SSL additions for server -> server communication. The > SecurityTool was used on both sides. I admit to not testing the client > code that thoroughly. > > >>SecureXmlRpcClient c = new SecureXmlRpcClient("https://blahblah:8888/RPC2";); >> >>c.execute(...) > > > Did you try using the SecurityTool? >
I don't quite know how the SecureXmlRpcClient is using the properties in SecurityTool. In particular, I don't see the reference to SecurityTool in both SecureXmlRpcClient and the plain XmlRpcClient class. When invoking the execute, both classes go through the same worker execute code (which involks the URLConnection constructor and the construction of the URL complains that https is not a valid protocol). I do not think I see the switch from non-secure to secure code there....:( There's this nice mechanism in the webserver side though. I can just overwrite the function to create the socket so I can do whatever I want. I don't see this in the client code. Maybe it's time to do some hacking myself...;) -- William Lee (Will) | Sendmail Inc. Email: [EMAIL PROTECTED] | http://www.sendmail.com Tel: (510) 594-5505 |
