FAQ
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.

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.

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.

Thank you

--
S pozdravem
Marek Janda

Search Discussions

  • Alexis Richardson at May 4, 2009 at 6:29 pm
    Marek,
    On Mon, May 4, 2009 at 6:08 PM, Marek Janda 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...

    alexis




    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
  • Marek Janda at May 4, 2009 at 7:33 pm
    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.
    On Monday 04 May 2009, Alexis Richardson wrote:
    Marek,
    On Mon, May 4, 2009 at 6:08 PM, Marek Janda 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...

    alexis
    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

    --
    S pozdravem
    Marek Janda
    email: nyx at nyx.cz
    GnuPG: http://nyx.nyx.cz/files/nyx.gpg
  • Alex Clemesha at May 4, 2009 at 8:13 pm

    On Mon, May 4, 2009 at 12:33 PM, Marek Janda wrote:

    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.
    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.


    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.
    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




    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:
    Marek,
    On Mon, May 4, 2009 at 6:08 PM, Marek Janda 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...

    alexis
    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

    --
    S pozdravem
    Marek Janda
    email: nyx at nyx.cz
    GnuPG: http://nyx.nyx.cz/files/nyx.gpg

    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


    --
    Alex Clemesha
    clemesha.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090504/a5bfd3bf/attachment.htm
  • Matthias Radestock at May 4, 2009 at 7:45 pm
    Marek, Alexis,

    Alexis Richardson wrote:
    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.
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedMay 4, '09 at 5:08p
activeMay 4, '09 at 8:13p
posts5
users4
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase