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 own :P > 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. > > --Rafael 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> > wrote: > >> 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 >> >> >>
