qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Java Client -> C++ broker anonymous authentication weirdness - does anyone know this stuff??
Date Mon, 04 Feb 2013 12:29:47 GMT
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: 

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://'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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message