Hi Chuck,

Thanks for the links to the documentation. I should have found it earlier -
it would have been easier then digging through the tests :-). I used only
the "book" part before, and there are no details about the access control
policy.

I raised DISPATCH-330 <https://issues.apache.org/jira/browse/DISPATCH-330> JIRA
to cover the error type issue.

Thanks & Regards
Jakub

On Mon, May 9, 2016 at 7:33 PM, Chuck Rolke <[email protected]> wrote:

>
>
> ----- Original Message -----
> > From: "Jakub Scholz" <[email protected]>
> > To: [email protected]
> > Sent: Monday, May 9, 2016 11:57:10 AM
> > Subject: Dispatch access control policy - what is the idea behind
> applicationName?
> >
> > 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.
>
> There is some explanation in qpid-dispatch/doc/notes/qdr-policy-01.pdf
>
> An informal to-do list is in qdr-policy-todo.md. That includes your
> suggestion
> of differentiating unauthorized-access from resource-limit-exceeded errors.
> The to-do list was my working checklist while policy was still on a private
> branch and every addition didn't need a jira. Today your suggestions should
> go in as jiras so they don't get lost.
>
> Regards and thanks,
> Chuck
>
> >
> > Thanks & Regards
> > Jakub
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to