Running Business Processes and Composite Applications 10.5 | Running Business Processes and Composite Applications | Universal Messaging Administration Guide | Universal Messaging Enterprise Manager | Administering TCP Interfaces, IP Multicast, and Shared Memory | Creating Interfaces | Usage of 0.0.0.0 When Defining Interfaces
 
Usage of 0.0.0.0 When Defining Interfaces
When a client connects to a server, the server will deliver all interfaces that are marked as "advertised" (this is, set using the check box Advertise Interface on the Comms > Interfaces > Basic tab). If you have interfaces bound to 0.0.0.0 (that is all known interfaces), then this will include both 127.0.0.1 (localhost) and any IP address that the server node has. This means that the client will receive at least two interfaces that it will use to reconnect to the realm.
If the client connection is restarted, the client will attempt to iterate through this list of interfaces until it is successful on reconnection. However, the order of iterating through this list is not deterministic.
On a successful connection, the Universal Messaging realm server will construct a client principal name in the format <userName>@<IP-Address> used to check permissions on realm resources, such as channels or queues, where <IP-Address> is the IP address of the machine where the client is running. The IP address of the client in turn depends on the network interface the client used to connect to the server. In the example with a server adapter bound on all network interfaces (0.0.0.0), a local client (on the same machine as the server) may connect over the loopback interface to the server (localhost) so the connection will come from 127.0.0.1, but that same client may also connect over the real network interface, in which case the IP address will be the address of this network interface. Thus one and the same client may end up with different principal names when reconnecting to the realm server. This may lead to permission issues if a resource's default ACL has been established using one principal name, and is subsequently accessed with a different principal name after a reconnection.
To avoid this, you should either create the interface for an external IP address (not "localhost") or ensure that required ACLs are configured.

Copyright © 2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.