qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: IP white-lists for brokers
Date Mon, 07 Dec 2009 20:06:50 GMT
Existing users of the ACLs have had to suffer quite a bit (see the JIRAs
fixed in the last couple of releases), thus my impression is that
there is/was a real motivation for not making big changes there.

We need to maintain (at least) backward compatibility so that we don't cause
users with production ACLs migration/test overhead.

I don't have any objection with the idea of bringing the ACLs together, but
for me the big caveat is test coverage since that was the issue (really)
with the old ACLs.


On Mon, Dec 7, 2009 at 7:59 PM, Carl Trieloff <cctrieloff@redhat.com> wrote:

> Aidan Skinner wrote:
>> On Mon, Dec 7, 2009 at 5:16 PM, Rajith Attapattu <rajith77@gmail.com>
>> wrote:
>>> However I'd like to see similar functionality/behaviour implemented by
>>> our brokers for a given requirement where possible.
>>> The Java brokers ip-whitelisting feature is standalone atm.
>>> So wondering if there is any interest in combining with the ACL, or
>>> why it wasn't done that way as it maybe due to some factors that I
>>> have overlooked.
>>> Also irrespective of how it's implemented I am keen to have the same
>>> test cases against both brokers to ensure we share the effort.
>> Martin and I kicked about the idea of integrating the two at one
>> point, but didn't due to logistical problems with the current ACL
>> implementation in the Java broker. It seemed to make more sense to do
>> it as an extension to the shared ACL format, but that patch never
>> quite seems to go in.
>> Adding in a "from <netmask/hostname>" would be pretty simple syntax
>> wise, and similar to what things like PostgreSQL do. It's a shame the
>> @ syntax is already taken, but nm.
>> Something like this perhaps?
>> acl allow user from localhost
>> acl allow user from
> yes, following the format for acl below would be very intuitive and not
> introduce another
> mechanism to that would have to be documented.
> Carl.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message