On 4/20/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > On 4/20/06, James Strachan <[EMAIL PROTECTED]> wrote: > > On 4/20/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > Hi Mike, > > > > > > Thanks for the info! So all the real magic is in: > > > ((SSLSocket)socket).setNeedClientAuth(needClientAuth) and > > > ((SSLSocket)socket).setWantClientAuth(wantClientAuth); > > > > > > I'm going to apply a patch so you can do this and also set any other > > > properties on the socket. First off, when binding a tcp transport, > > > you will be able to use "transport." prefix on properties to configure > > > the options on the transports the connector creates. Secondly, you > > > will be able to configure options on transport's the socket using the > > > "socket." prefix on the transport options. > > > > > > So if you need clientAuth on the sockets created by ssl transport > > > connector, you would use: > > > ssl://localhost:616167?transport.socket.needClientAuth=true > > > > Isn't 'transport.' superflous? i.e. ssl is a transport, so can't we just use > > > > ssl://localhost:616167?socket.needClientAuth=true > > > > Sorta.. but not really. On the server side, what you really are > configuring is that transport server which could have totally > different set of properties from an actual transport. Previously we > had been duplicating transport properties on the server object just so > that they could also be applied to the transport when it got created > (the server actually did not use them). > > So design wise it's a bit cleaner to have the "transport." prefix.
Ah - I missed that the transport.* stuff is set on the transports created on the TransportServer :) So you're right - the transport prefix makes most sense. > A > client that is establishing connection to the server would only need > to use the: > > ssl://localhost:616167?socket.needClientAuth=true Got it - nice :) -- James ------- http://radio.weblogs.com/0112098/
