On 6 July 2015 at 18:57, Rafael Schloming <r...@alum.mit.edu> wrote:
> 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,
Yes, it almost seems like a change in default behaviour of a sasl
enabled server to allow non-SASL connections should have a JIRA of its
> 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.
I can agree with that. Although I do feel the defaults for both
engines (independent from the defaults of any of our other code that
uses them, which can do anything it likes) are now wrong as a result
of this latest change ;)
> 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.