[rabbitmq-discuss] direct exchanges / routing key necessary?
nyx at nyx.cz
Mon May 4 20:33:56 BST 2009
In my case, RK is generated from username and session, so it changes for every
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.
On Monday 04 May 2009, Alexis Richardson wrote:
> On Mon, May 4, 2009 at 6:08 PM, Marek Janda <nyx at nyx.cz> wrote:
> > Hello,
> > I just need to confirm one thing.
> > If I send some message to direct exchange, is there any way to bind queue
> > to it that you'll get the message even without knowing it's routing key?
> > I want to use RK as a "password" so that every user can subscribe only to
> > messages addressed to him - so I need to know if there isn't some way to
> > create wildcard match and subscribe to all messages.
> 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.
> > After reading documentation, searching the web and looking into source
> > (well, I've seen Erlang for the first time in my life), I think it should
> > require the key, but I'd like to be 100% sure I didn't miss anything.
> 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.
> > Also, is it ok to send everything to one exchange or should I create more
> > exchanges and divide users between them? From the performance POV.
> 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...
> > Thank you
> > --
> > S pozdravem
> > Marek Janda
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-discuss at lists.rabbitmq.com
> > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
email: nyx at nyx.cz
More information about the rabbitmq-discuss