[rabbitmq-discuss] direct exchanges / routing key necessary?

Marek,
As I recall there are no wildcards with direct exchanges.

Wildcards are appropriate for topic exchanges where they are explicit
(*, #), and fanout exchanges where they are implicit since fanout
implement full broadcast to all bound queues.

However, note that with direct exchanges there is nothing in the spec
to prevent someone who knows the password binding to a given exchange
once they know the key. So if I know your password then I can see a
copy of your messages, as well as mine. And vice versa.

You may want to look at ACLs in RabbitMQ:
http://www.nabble.com/ACLs-td21615692.html Users who do not have
permission to manage their own bindings, and who can only send and
receive messages, will not be able to add bindings and hence
compromise your scheme. I think but am not 100% that this is possible
with how RabbitMQ currently implements ACLs.

:-)

I am hopeful that one of the RabbitMQ engineers will substantiate or
correct my comments above with some detail. It's a holiday weekend
here in the UK so this may not happen instantly.

In the case of RabbitMQ that's somewhat moot and depends on the
details of your use case. Fanout exchanges are computationally
cheaper than direct, since there is one fewer lookup step, and topic
exchanges are more complex than direct. But there may be other
factors to consider.

If you wanted to implement the twitter follower pattern for example,
you could EITHER use one direct exchange (bind to the exchange with
the key of the person you follow), OR have one fanout exchange per
user (bind to the exchange of anyone you follow). Happy to explain
more if you like...

alexis

Thank you

In my case, RK is generated from username and session, so it changes for every
login.

I'm using Orbited to implement Comet (sending events from server to browser)
and I'm dealing with possibility (well...certainity) that some users will open
multiple browser tabs and I'll need to send the message to all of them.

So I have to create uniquely named queue for every browser tab/connection and
bind them all to exchange with the same RK. If I use the same queue for all
tabs, message will be sent only to one of them.

Possible attacker could:
1) guess RK, create new queue and bind it to exchange with that RK
2) guess name of existing queue and subscribe to it - unlikely, as queues are
quite short-lived - after user leaves page, current queue is destroyed and new
is created on next page (messages send in between are handled outside MQ)

If attacker could sniff their RK, they could as well read all their messages
anyway, so I don't see those two options as real danger.

So unless there is some option 3) that would allow attacker to consume from
exchange without knowing RKs, I think I'm safe.

There may be other possibilities - like dropping whole exchange and creating
it with different type - I'm using default amq.direct, so I'm not even sure
it's possible - have to try.

Other ideas are welcome of course.

// Users themselves don't publish anything to MQ...they just send ajax request
to server and messages are published from server, so users don't need to know
other user's RK.

Are you working on a project that is open source? If so, and you'd like to
provide
a link to your project please do. I'd be interested to see how you get on
with this.

This is slightly off-topic for the RabbitMQ list, but from what I understand
browsers
actually restrict the total number of connections to a given server. It's
something
like 2 for Firefox, and IE has the same (all per the http 1.1 spec).
Are you solving this in some interesting way like creating multiple
subdomains
(I think facebook does this) ... or some other way?


Anyways, love to hear how you get on tying together Orbited and RabbitMQ.

thanks,
Alex

Marek, Alexis,

Alexis Richardson wrote:
ACLs can indeed do this, though the above approach requires that the
queues and bindings must be created by a "superuser", which may or may
not fit the use case here.

NB: The implementation of ACLs has not made it into an official release
yet, and it is slightly different than what is documented in the above link.


Regards,

Matthias.