On 12/05/16 18:33, Chuck Rolke wrote:
* The "TCP connection level host (network host)" has no useful
information. That will always be the address of the router itself
and has no hint about where the user was trying to go.
Version 2 in practice is simply the open.hostname. [1]
You could have more than one interface and e.g. expect that more
sensitive operations are only allowed on one of them.
* A patch went into 0.6 this week that defines a fallback policy that
has rules and settings for open.hostname values that are not
defined in the router's policy database. It now works as:
IF open.hostname in policy-ruleset-db:
use policy-ruleset-db[open.hostname]
ELSE
IF fallback-enabled:
use policy-ruleset-db[fallback]
ELSE
connection disallowed - no defined policy
* I like the concept in Version 1 of allowing some kind of
connection.properties["application-id"] = "virtualhost"
** This lets users whose clients do not put the right thing into
open.hostname participate in Dispatch networks before an updated
client comes along.
Assuming of course that the connection properties are settable in such
clients (not sure how likely that actually is, for the proton python
'container' api for example it is not, neither would it be for
qpid::messaging I don't think).
In any case it feels like a hack to workaround a defect in clients. If
thats what we want (and there are concrete cases where it will help) we
should call the property x-hostname or something similar, and deprecate
it from the start.
I don't think the ideal is for applications to have to set this sort of
thing. They should just be given a host and port to connect to.
** This will work today.
** The router could be configured to allow this property to control
policy or not.
That just seems like additional complexity in the code and the tests.
** I see no more risk in adding this property than in using the
open.hostname. Determined users can steer the open.hostname
to have whatever they want. [2]
My argument isn't really about risk. Its about what the clients should
or should not be concerned with. The concept of a virtual host is well
understood; the concept of 'application' is not really. In any case
users don't even need to care if the host is virtual or not.
As well as open.hostname, there is the ssl name indication and the
sasl-init.hostname.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
