<div>
                    Hey Simon,
                </div>
                <div></div>
                 
                <p style="color: #A0A0A8;">On Thursday, 17 January 2013 at 11:20, Simon MacMullen wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div>Yes, but that shouldn't be too problematic - while all our auth </div><div>mechanisms invoke rabbit_access_control:check_user_pass_login/2 or </div><div>similar (which ends up looking up and driving auth backends), you could </div><div>write an auth mechanism which either drives an auth backend directly, or </div><div>contains its own auth backend. Then it can do whatever it wants - the </div><div>contract of an auth mechanism is to reject login or provide a user.</div></span></blockquote><div><br>
                </div><div>Since I posted a number of times into this thread, I'm not sure which question you are answering here. My latest question was about the fact that I could encode the</div><div><ul><li>username;</li><li>password;</li><li>vhost;</li><li>(optional) radius token, depending on whether the specified vhost is subject to a extra token verification or not;</li></ul>into the SASL payload and my custom rabbit_auth_mechanism would decode this, and decide based on the vhost supplied whether to perform a lookup on the token. All of this is up to this custom implementation.</div><div><br></div><div>What I don't understand about your observation may stem from my misunderstanding the flow of the handshake during AMQP connection establishment. I was assuming that due to the sequence of AMQP frames defined in the protocol, Rabbit would initially delegate the authentication to my custom&nbsp;rabbit_auth_mechanism, which could present vhost X. Once this callback has successfully done everything it needs to do and returns a user back to Rabbit, then the client would be able to send a connection.open frame. At this point, the client could potentially encode vhost Y into that frame, and hence effectively by-pass the logic of the&nbsp;custom rabbit_auth_mechanism.</div><div><br></div><div>Maybe I'm missing the point here.</div><div><br></div><div>Having said all of this, in the meantime I've come up with an alternative solution - just run separate Rabbit instances for each vhost.</div><div><br></div><div>Cheers,</div><div><br></div><div>Ben</div><div><br></div><div><br></div><div><br></div><div><br></div>