N.B. The original implementation of LookupLocator only performs Unicast
Discovery V1, it cannot be changed because of a static final field for
the protocol version.
We could create a builder, perhaps called LookupLocatorBuilder, which
returns ConstrainableLookupLocator if security is desired.
This could also build all the necessary constraints.
LookupLocatorBuilder llb = new LookupLocatorBuilder();
LookupLocator locator =
llb.host(name).port(4062).authenticate(true).confidentiality(true).build();
Cheers,
Peter.
Peter Firmstone wrote:
Hi Gregg,
You can use an instance of ConstrainableLookupLocator to perform
Unicast V2 discovery, it is also an instance of LookupLocator.
Discovery V2 also supports Kerberos and SSL, Discovery V1 has no
security.
Discovery V1 uses MarshalledObject serial form to transfer the
Registrar proxy, Discovery V2, uses MarshalledInstance.
I'm currently investigating methods of preventing the deserialization
and unmarshalling attacks during discovery, Discovery V1 cannot be
fixed (MarshalledObject related) however Discovery V2 can be.
Regards,
Peter.
Gregg Wonderly wrote:
I use LookupLocator as a basic form of service end point
description. Many of my deployments are across non broadcast
networks and I must use unicast lookup via LookupLocator.
Sent from my iPhone
On Nov 9, 2010, at 1:25 PM, Peter Firmstone <j...@zeus.net.au> wrote:
Sim IJskes - QCG wrote:
On 09-11-10 12:53, Peter Firmstone wrote:
LookupLocator is used by LookupLocatorDiscovery as little more than a
String URL parser, to store the host and port information.
Could you also have a look at LookupLocator. I was looking for the
methods usage for the methods you deprecated, but couldn't find any
reference. Is it still a functional part of code?
Gr. Sim
ConstrainableLookupLocator overrides the methods and performs
Discovery V2, so I decided to simply add some more javadoc and
relevant references to clear up any confusion instead.
