Hi Justin, It sounds like something what is very useful in some use cases, but might make live complicated in other use cases.
In my case, I do not need to have multiple applications in one Dispatch instance. I need just one application. I have also many customers with their own applications which I want to connect to the router. These are out of my control - so it is hard to make sure that they use the same settings. The clients are also often located in very specific network environments - so I cannot expect that setting the hostname automatically based on where they are connecting to will produce some consistent results. There is always someone connecting using some private IP through his proxy / firewall / network router to connect to our brokers. As I see it right now, I would need at least three different applications: - Application named "" which will match Qpid Messaging clients which seem to ignore the hostname completely - Application named after IP address for clients connecting using IP address - Application named after DNS hostname for those clients who used the DNS name (in reality it will be worse, because of several network interfaces) I think there needs to be a simple way how to handle such use case. As a quick ideas which come to my mind: - Wildcards in the application name (e.g. "*" to cover all possible hostnames) - Default policy which would apply when there is no patching application policy Thanks & Regards Jakub On Mon, May 9, 2016 at 6:58 PM, Justin Ross <[email protected]> wrote: > Hi, Jakub. Here's my proposal (two versions). > > ## Version 1 > > - Dispatch defines "applications" as policy domains > - Dispatch uses one of the following, in descending priority, to identify > the app: > - open.properties["application-id"] (real property name to be determined > later) > - open.hostname ("virtual host") > - TCP connection level host (the "physical" or network host) > - APIs and tools should offer ways to control the application ID and hence > override the policy domain that is used > > ## Version 2 > > - Dispatch defines "vhosts" as policy domains > - Dispatch uses one of the following, in descending priority, to identify > the app: > - open.hostname ("virtual host") > - TCP connection level host (network host) > - The policy domain in use can only be determined by virtual host or > network host > > I favor version 1, on the idea that dispatch policy domains should have a > more flexible scope. > > We have looked at defaulting the open.hostname to the connection host, and > we may yet be able to do this, but it introduces some problems. In any > case, we will offer the network host in a separate accessor, so servers > such as dispatch can use that information as a fallback to determine the > app. > > On Mon, May 9, 2016 at 8:57 AM, Jakub Scholz <[email protected]> wrote: > > > After spending some time playing with the access control policies in > > Disptach, I'm wondering what is the idea behind the applicationName > field. > > > > First I though that it is just a name for the policy ruleset wich I can > > choose as I want. But it seems to be connected to the hostname field in > the > > OPEN frame. Unfortunately, it looks like different clients put different > > information into the hostname. E.g. the qpid-send / qpid-receive tools > from > > the Qpid C++ broker installation don't set the hostname at all. The > qdstat > > utility from dispatch seems to set it to the hostname it is connecting > to. > > But it looks like the applicationName doesn't support wildcards. As a > > result, I need several different rulesets instead of having just one > > ruleset. > > > > Could someone explain to me how is it supposed to work? I din't found > much > > about it in the documentation. > > > > Thanks & Regards > > Jakub > > >
