On Wed, Sep 14, 2016 at 1:01 PM, Andrew Stitcher <astitc...@redhat.com>
> > ## host: 0.0.0.0 allows connection via localhost from qpid_messaging
> > but
> > not from proton
> > My qpid_messaging client can connect, using localhost in its
> > connection
> > info, but my proton client cannot (connection refused). Using '::'
> > instead
> > of '0.0.0.0' allows either to connect. Perhaps the way proton
> > resolves
> > localhost is different.
> 0.0.0.0 is an IPv4 address :: is the IPv6 equivalent.
> Usually localhost will map to both of these addresses, and the usual
> system defaults will try the IPv6 address first.
> So if the client code doesn't correctly try all the resolved IP
> addresses in order then you'll get this behaviour.
> I know that qpid.messaging does this correctly.
I'll raise a jira for this against proton once I create a small reproducer.
> > ## "authenticatePeer: on" strips ANONYMOUS
> What do you mean "strips" ANONYMOUS? Do you mean the mechanism isn't
> offered? The mechanism isn't in the allowable client list?
Yes, I mean it isn't offered. With the config I posted, I get an empty
mechanism list from the server.
> At the proton API level authenticatePeer means that we require
> connections to be authenticated before using them. This can either by
> via SASL or via SSL.
> So I wouldn't expect that setting to take ANONYMOUS out of the offered
> mechanisms, but I'm not 100% about the behaviour of Cyrus under all
> > This was a surprise to me. I had explicitly enabled ANONYMOUS. And
> > I
> > confess I was mentally reading 'authenticatePeer' to mean enable
> > SASL.
> > Which component is stripping it, proton or dispatch or cyrus? Should
> > it be
> > stripped when I positively express a desire for it?
> I'm not sure that forcing the ANONYMOUS mechanism together with
> authentication isn't contradictory - ANONYMOUS is explicitly
> unauthenticated (it's anonymous after all!).
Yeah. It goes to what authenticatePeer really means. It appears to mean
more than I assumed.