Jakub, my apologies. I did not properly understand your issue. I agree, having some way to set the policy beyond the scope of a single application is sensible.
On Mon, May 9, 2016 at 2:24 PM, Jakub Scholz <[email protected]> wrote: > 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 > > > > > >
