<br><br><div class="gmail_quote">On Mon, May 4, 2009 at 12:33 PM, Marek Janda <span dir="ltr"><<a href="mailto:nyx@nyx.cz">nyx@nyx.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thank you<br>
<br>
In my case, RK is generated from username and session, so it changes for every<br>
login.<br>
<br>
I'm using Orbited to implement Comet (sending events from server to browser)<br>
and I'm dealing with possibility (well...certainity) that some users will open<br>
multiple browser tabs and I'll need to send the message to all of them.</blockquote><div>Are you working on a project that is open source?� If so, and you'd like to provide<br>a link to your project please do.� I'd be interested to see how you get on with this.<br>
�<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
So I have to create uniquely named queue for every browser tab/connection and<br>
bind them all to exchange with the same RK. If I use the same queue for all<br>
tabs, message will be sent only to one of them.</blockquote><div>This is slightly off-topic for the RabbitMQ list, but from what I understand browsers<br>actually restrict the total number of connections to a given server.� It's something<br>
like 2 for Firefox, and IE has the same (all per the http 1.1 spec).<br>Are you solving this in some interesting way like creating multiple subdomains<br>(I think facebook does this) ... or some other way?<br><br><br>Anyways, love to hear how you get on tying together Orbited and RabbitMQ.<br>
<br>thanks,<br>Alex<br><br><br>�<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Possible attacker could:<br>
1) guess RK, create new queue and bind it to exchange with that RK<br>
2) guess name of existing queue and subscribe to it - unlikely, as queues are<br>
quite short-lived - after user leaves page, current queue is destroyed and new<br>
is created on next page (messages send in between are handled outside MQ)<br>
<br>
If attacker could sniff their RK, they could as well read all their messages<br>
anyway, so I don't see those two options as real danger.<br>
<br>
So unless there is some option 3) that would allow attacker to consume from<br>
exchange without knowing RKs, I think I'm safe.<br>
<br>
There may be other possibilities - like dropping whole exchange and creating<br>
it with different type - I'm using default amq.direct, so I'm not even sure<br>
it's possible - have to try.<br>
<br>
Other ideas are welcome of course.<br>
<br>
// Users themselves don't publish anything to MQ...they just send ajax request<br>
to server and messages are published from server, so users don't need to know<br>
other user's RK.<br>
<div><div></div><div class="h5"><br>
On Monday 04 May 2009, Alexis Richardson wrote:<br>
> Marek,<br>
><br>
> On Mon, May 4, 2009 at 6:08 PM, Marek Janda <<a href="mailto:nyx@nyx.cz">nyx@nyx.cz</a>> wrote:<br>
> > Hello,<br>
> > I just need to confirm one thing.<br>
> ><br>
> > If I send some message to direct exchange, is there any way to bind queue<br>
> > to it that you'll get the message even without knowing it's routing key?<br>
> > I want to use RK as a "password" so that every user can subscribe only to<br>
> > messages addressed to him - so I need to know if there isn't some way to<br>
> > create wildcard match and subscribe to all messages.<br>
><br>
> As I recall there are no wildcards with direct exchanges.<br>
><br>
> Wildcards are appropriate for topic exchanges where they are explicit<br>
> (*, #), and fanout exchanges where they are implicit since fanout<br>
> implement full broadcast to all bound queues.<br>
><br>
> However, note that with direct exchanges there is nothing in the spec<br>
> to prevent someone who knows the password binding to a given exchange<br>
> once they know the key. �So if I know your password then I can see a<br>
> copy of your messages, as well as mine. �And vice versa.<br>
><br>
> You may want to look at ACLs in RabbitMQ:<br>
> <a href="http://www.nabble.com/ACLs-td21615692.html" target="_blank">http://www.nabble.com/ACLs-td21615692.html</a> �Users who do not have<br>
> permission to manage their own bindings, and who can only send and<br>
> receive messages, will not be able to add bindings and hence<br>
> compromise your scheme. �I think but am not 100% that this is possible<br>
> with how RabbitMQ currently implements ACLs.<br>
><br>
> > After reading documentation, searching the web and looking into source<br>
> > (well, I've seen Erlang for the first time in my life), I think it should<br>
> > require the key, but I'd like to be 100% sure I didn't miss anything.<br>
> ><br>
> :-)<br>
><br>
> I am hopeful that one of the RabbitMQ engineers will substantiate or<br>
> correct my comments above with some detail. �It's a holiday weekend<br>
> here in the UK so this may not happen instantly.<br>
><br>
> > Also, is it ok to send everything to one exchange or should I create more<br>
> > exchanges and divide users between them? From the performance POV.<br>
><br>
> In the case of RabbitMQ that's somewhat moot and depends on the<br>
> details of your use case. �Fanout exchanges are computationally<br>
> cheaper than direct, since there is one fewer lookup step, and topic<br>
> exchanges are more complex than direct. �But there may be other<br>
> factors to consider.<br>
><br>
> If you wanted to implement the twitter follower pattern for example,<br>
> you could EITHER use one direct exchange (bind to the exchange with<br>
> the key of the person you follow), OR have one fanout exchange per<br>
> user (bind to the exchange of anyone you follow). �Happy to explain<br>
> more if you like...<br>
><br>
> alexis<br>
><br>
> > Thank you<br>
> ><br>
> > --<br>
> > S pozdravem<br>
> > Marek Janda<br>
> ><br>
> > _______________________________________________<br>
> > rabbitmq-discuss mailing list<br>
> > <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> > <a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br>
<br>
</div></div><font color="#888888">--<br>
S pozdravem<br>
Marek Janda<br>
email: � � �<a href="mailto:nyx@nyx.cz">nyx@nyx.cz</a><br>
GnuPG: � � �<a href="http://nyx.nyx.cz/files/nyx.gpg" target="_blank">http://nyx.nyx.cz/files/nyx.gpg</a><br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alex Clemesha<br><a href="http://clemesha.org">clemesha.org</a><br>