[rabbitmq-discuss] Questions about how best to use RabbitMQ

Steve Jenson stevej at gmail.com
Mon Nov 3 19:56:15 GMT 2008


On Mon, Nov 3, 2008 at 11:27 AM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Steve,
>
> On Mon, Nov 3, 2008 at 6:56 PM, Steve Jenson <stevej at gmail.com> wrote:
>> It seems like what I want is to setup a fanout exchange linked to one
>> queue per customer protected with user credentials. Previously I was
>> using realms and ACLs to do this but I understand that's going away.
>> What would be a better way to do this in RabbitMQ?
>
> ACLs and the rationale behind removing realms have been discussed on
> this list, see this thread for example:
>
> http://www.nabble.com/Access-control-documentation-td19506900.html
>
> So the current vhost ACL mechanism is going to be too coarse grained
> for what you want to achieve. With the current broker, you would have
> to implement the access control in your application.

I see, so we wouldn't be able to take advantage of fanout exchanges?
Fanout exchanges seem efficiently implemented such that each queue
doesn't keep an individual copy of the message. If we can't use fanout
exchanges, that would seem to indiciate increased memory pressure on
the broker?

> Having said that, implementing some useful access control mechanisms
> are on the mid to long term roadmap. These would most likely be
> orthogonal to the protocol and as indicated in a previous post, *may*
> include a capability based mechanism.

Very interesting. Do you mean capabilities in the KeyKOS/E language sense?

> Contributions in the form of requirements and analysis (e.g. by
> contributing to our wiki) or in the form of code, would help
> accelerate the implementation.

I would be happy to give our motivations for we're hoping to achieve.
We want to be able to setup partners with access to queues where they
can read and ACK read items without being able to create new exchanges
or queues. We want a single user to be able to setup exchanges and
bind queues to that exchange.

Best,
Steve




More information about the rabbitmq-discuss mailing list