Hi, Nybras:<br><br><div class="gmail_quote">On Sat, Jan 26, 2013 at 11:27 AM, nybras <span dir="ltr">&lt;<a href="mailto:brettflitter@gmail.com" target="_blank">brettflitter@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi I don&#39;t really understand how to use the regular expressions to dictate<br>
what the user can and can&#39;t do in the management plugin.<br></blockquote><div><br></div><div>Please see here: �<a href="http://www.rabbitmq.com/management.html">http://www.rabbitmq.com/management.html</a></div><div><br>
</div><div>Note also, that things changed and became a bit more flexibly a few versions ago.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m also not really sure about how to go about security. At the moment I&#39;ve<br>

created an app which connects just through one account (admin/root account)<br>
with no permission restrictions which I&#39;m guessing is not good.</blockquote><div><br></div><div>Probably not. �You&#39;d want to create a user account for that app, and then adorn it with the permissions needed to perform the various AMQP operations it needs to perform as it goes about its business.</div>
<div><br></div><div>See here for summary information: �<a href="http://www.rabbitmq.com/access-control.html">http://www.rabbitmq.com/access-control.html</a></div><div><br></div><div>Note that rather than an ACL, listing who can do a thing to an AMQP object, the permissions model works the other direction, perhaps slightly more akin to a bare bones capabilities system.</div>
<div><br></div><div>In the Rabbit model, a user has configure, read and write permissions. �Associated with each is a regex naming the resources that the user is allowed to configure/read/write. �Each AMQP command requires the resource it&#39;s trying to operate on to match the appropriate permission regex as summarized in the table at�<a href="http://www.rabbitmq.com/access-control.html">http://www.rabbitmq.com/access-control.html</a></div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> �Do I create<br>
a &#39;user&#39; account for each new user that uses my app or I do I create one<br>
&#39;user&#39; account with restricted permissions that all users can connect<br>
through??<br></blockquote><div><br></div><div>That depends on your application. �If the users of your messaging system really need disparate and partitioned access control, you may have to create multiple accounts. �Otherwise, it&#39;s common to see multiple logical applications in a broker (e.g. payment processing, status updates, etc.) and to perhaps create a user per logical app with suitable permissions, assuming of course there isn&#39;t going to be a single user whose concerns span the entities of both. �You can also segregate at the virtual host level which is an even sharper division.</div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve started using the http API so I can make requests to see how many<br>
bindings a user has made which is also currently being accessed through this<br>
&#39;one admin account&#39;, should I just create a basic user account to allow<br>
these GET requests? Again I don&#39;t understand what to do with the regular<br>
expressions.<br></blockquote><div><br></div><div>For access to management capabilities themselves, things are a bit different. �The management plugin extends the basic AMQP permissions model up above and allows arbitrary tags to be attached to users. �The management plugin respects tags called &quot;management&quot;, &quot;monitoring&quot; and &quot;administrator,&quot; each of which has different powers over administrative functions as summarized at: �<a href="http://www.rabbitmq.com/management.html">http://www.rabbitmq.com/management.html</a></div>
<div><br></div><div>Give those links a look, see how well they digest, and by all means return if you have further questions!</div><div><br></div><div>Best regards,</div><div>Jerry</div><div><br></div></div>