FWIW, my changes in this area really represent the minimum diff necessary
to get the reactor branch to land. None of this is related to the reactor
changes per se, it just so happens the reactor tests include several tests
that check interop between proton-c and proton-j and these tests keep
stumbling over incompatibilities that are currently quite easy to arise
given the current state of the sasl implementations.

While I agree 100% that the APIs should converge, at the moment I'm
actually slightly more worried about the on-the-wire interop issues. More
specifically, while it's bad for proton-c and proton-j APIs to look
different, it's *really* bad if the default settings for one result in a
configuration that won't interop with the default settings for the other.


On Mon, Jul 6, 2015 at 10:28 AM, Andrew Stitcher <astitc...@redhat.com>

> On Mon, 2015-07-06 at 13:14 -0400, Andrew Stitcher wrote:
> > On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
> > > ...
> > > The old toggle only used to define whether sasl was required or not
> > > (which it historically was once you enabled the sasl layer, and the
> > > toggle was never implemented in proton-j), whereas IIRC the new
> > > 'requireAuth' governs that but also whether ANONYMOUS is allowed or
> > > not when a SASL layer is used, is that correct?
> >
> > That is true, but I think it actually more useful to be able to select
> > authenticated or not compared to using SASL or not (because ANONYMOUS is
> > unauthenticated but uses SASL).
> >
> > The C implementation does the actual enforcement when it reads the AMQP
> > header, which would obviously be a significant change to the Java
> > implementation, but I really do think gives a more satisfactory user
> > result.
> The reason for the complexity and the checking at AMQP header time is to
> allow SSL certificates as a valid form of authentication (not
> necessarily only used with SASL EXTERNAL). If you don't need to support
> that (or at least not yet) then "require authentication" can simply mean
> require the SASL layer but don't offer the ANONYMOUS mechanism. That is
> what earlier versions of the C code did*, and I think that would be
> relatively simple to implement in Java too.
> * The C code will still not offer ANONYMOUS as a possible mechanism if
> authentication is required. But the overall meaning of the flag is more
> complex than this as explained.
> Andrew

Reply via email to