On Nov 9, 2005, at 11:18 AM, Rick McGuire wrote:
Kresten Krab Thorup (JIRA) wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-1145?
page=comments#action_12357111 ]
Kresten Krab Thorup commented on GERONIMO-1145:
-----------------------------------------------
In the A-B-C scenario, why is it that the relevant CSS info is not
included in the reference? If we use the correct ORB when
generating the reference in the first place, why is this
information lost later on?
In the scenario where we ran into this, the information was in the
IOR, and that information was used to decide that a secure
transport was required. At a minimum, the Supports and Requires
information was encoded in the IOR. However, as currently setup,
the ORB uses its own configuration information for sending the
request. And because it was getting dispatched to an ORB instance
that was not configured to use secure transports, the call failed.
It really appears the ORB should be respecting the profile encoded
in the IOR when making callbacks, separate from its profile
requirements for publishing its own IORs.
Right. an IOR is exactly that: an recipe for how to contact a server
object, and this includes options and constraints for security. This
information may have to be applied to a "logical and" with client
security constraint before an attempt is made to contact the server.
So in this case, C's TSS should be encoded into the handle, and this
info should stay there across the call to B, so that A can see C's
TSS info in the IOR.
In this sense, there is no difference between a callback and other
kinds of call. A call is a call, and it should respect the
requirements of the target's IOR. An IOR is immutable, and the
profiles contained in it should not be changed because it is passed
through an intermediary.
Kresten
