On 02/02/2013 12:02 PM, Fraser Adams wrote:
So I'm thinking that there might have been some changes between Qpid versions? I've currently got the 0.20 Java jars on my classpath, but my broker is still 0.12, but Bruno reckons he's been using 0.18 at home and I think 0.14 at work so my hunch is that something might be different between the brokers?
I don't think anything has changed on the broker side in that regard. I strongly suspect any change in behaviour is on the client side.
[...]
it seems to be the explicit setting of sasl_mechs='ANONYMOUS' that is significant.
[...]
Could someone please explain how this hangs together (and is my observation about right?).
The mechanism is chosen by the client. If not explicitly specified it should pick one of the mutually supported ones (ideally the 'most secure').
My guess is that something has changed on the client side around the selection of a mechanism when none is provided(?). I can't say for sure however (the only relatively recent change I saw in the logs was: http://svn.apache.org/viewvc?view=revision&revision=1424556).
Anyone more fmailiar with the JMS client able to comment on the logic involved in selecting a SASL mechanism when it has not been explicitly chose through the 'URL'? Or on any recent changes to that?
What I'd really like to do is to put a fix into my code that will behave correctly irrespective of the broker/client runtime version. It looks like Bruno doesn't have to explicitly add the sasl_mechs bit for anonymous, but does it hurt? So for example if in my ConnectionHelper if I don't get an explicit username or password as part of the input and I default to an output URL of the form amqp://:@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672?sasl_mechs='ANONYMOUS'' Is that likely to be an issue? Clearly this would be a bad thing to do if an actual username was supplied :-)
Ultimately I think you may want to allow the acceptable mechanisms to be supplied as well as the username and password.
However, I would also say that I think the issue Bruno hit sounds very much like a JMS client bug. The client should only set the userid to the *actual* authenticated user and it sounds like that may not be the case. I think we should raise a JIRA for that anyway.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
