> -----Original Message----- > From: Polar Humenn [mailto:[EMAIL PROTECTED] > Sent: 13 March 2007 13:32 > To: [email protected] > Subject: Re: http: URLs and setepURL > > If you set up "configuration" with trust deciders and other > security related stuff, you are fooled into thinking you are > actually protecting the send to one endpoint, when in fact > it's getting shipped off to a completely different endpoint > than the one you configured.
There's no foolin' going on here IMO. Here's the way I'd see it working ... 1. Conduit.send() figures out the endpoint address it should use, from the EndpointInfo or EPR, possibly over-ridden by the Message.ENDPOINT_ADDRESS property. 2. Conduit.send() opens the connection. 3. Now the Conduit knows exactly what the endpoint address is (modulo IP spoofing), plus possibly some other security-related info (such as the TLS context in the case of HTTPS) 4. This connection-related info, plus the Exchange, is passed from Conduit.send() to TrustDecider.establishTrust() so it can make a trust evaluation 5. If trust is denied, the connection is immediately shut down without any data being written, and presumably an Exception is propagated up the application code So nothing is ever given the wrong impression as to the actual endpoint that'll be invoked on. Note that I wrote Conduit.send() above as opposed to HTTPConduit. With a bit of creativity, this functionality could I guess be put into the AbstractConduit so as to be available to all transport impls, if you can come up with generic "target endpoint" and "security context" representations to pass into a cross-transport TrustDecider. But initially, it probably only makes sense for HTTP, because this is the only transport that gives us the TLS context (i.e. via the HttpsURLConnection.getCipherSuite()/getServerCert() etc APIs). /Eoghan > If that's allowed to happen, then you have no assurance what > is happening and you just might as well protect things down > at a lower level with VPN stuff. > > Cheers, > -Polar > > > Dan Diephouse wrote: > > I tend to agree with Polar that it is kind of weird. I thought the > > idea was that a Conduit is supposed to be a Conduit to a particular > > endpoint, not many. > > > > BUT there is the practical issue of configuration. We may want to > > configure our conduit based on: > > 1. The particular jax-ws client & the wsdl port it is talking to 2. > > The particular URL 3. Both 1 & 2. > > > > The problem with #1 is that you have to put in the logic in > conduits > > that we already have. The problem with #2 is that we can't have > > different clients talk to the same url with different settings. > > > > I guess we could go down the route of: > > - If a different EPR is specified create a new Conduit in the > > MessageSenderInterceptor > > - Apply the configuration to the new conduit like it would > be applied > > to the original conduit > > > > But wouldn't that be pretty much equivalent (at least for > the HTTP case)? > > > > - Dan > > > > On 3/12/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> > -----Original Message----- > >> > From: Polar Humenn [mailto:[EMAIL PROTECTED] > >> > Sent: 12 March 2007 20:28 > >> > To: [email protected] > >> > Subject: http: URLs and setepURL > >> > > >> > In the HttpConduit I have noticed that the "url" for the > conduit is > >> > set up in the constructors from the EndpointInfo, or the > >> > EndpointReferenceType. > >> > > >> > However, it maybe totally overridden in send(Message) by the > >> > Message.ENDPOINT_ADDRESS on the message. What purpose > does this have? > >> > >> > >> I'd imagine the purpose is to support the standard JAX-WS > mechanism > >> whereby the application can explicitly control the target > address by > >> setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on > the request > >> context. > >> > >> > >> > Shouldn't this conduit ONLY be sending messages to the endpoint > >> > designated (configured) for it? > >> > >> > >> Not necessarily. > >> > >> The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to > >> give the client application the flexibility to override the target > >> endpoint address if necessary. For example the service may have > >> migrated to a new address, but the WSDL or annotated Java > available > >> to the client app may be out-of-date. > >> > >> > >> > Furthermore, the code fragment in setupURL > >> > > >> > String result = value != null ? value : url.toString(); > >> > if (null != pathInfo && !result.endWith(pathInfo)) { > >> > result = result + pathInfo; > >> > } > >> > > >> > has a bit of a caveat in that you'd never be able to > send a request > >> > to a location of "http://somewhere.com/xx/xx";, > specified by a URL > >> > of "http://somwhere.com/xx"; a Message.PATH_INFO property > of "/xx". > >> > >> > >> If you think this is an important usage scenario, feel > free to submit a > >> patch with a fix. > >> > >> > >> > Now some might say "why would you want to do that?" I know > >> > "xx" doesn't make sense to most, but what about, > >> > > >> > "http://somewhere.com/path/to/parent/.."; > >> > > >> > as a URL location built up from other things you might have > >> > dealt with, and you want to set a path from there to be "/.." > >> > Then you are in a completely different location than you > want to be. > >> > > >> > Is there a specific "contract" are placed on > >> > Message.ENDPOINT_ADDRESS, Message.PATH_INFO for this > >> > situation, or its it a bug? > >> > > >> > Cheers, > >> > -Polar > >> > > >> > > >> > > > > > > > >
