On 6 July 2015 at 18:28, 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 >
Yeah, I appreciated that, I just didn't think it necessary detail for the fairly basic point I was trying to make. As mentioned in my last mail, I was really just pointing out the mismatch between the existing behaviour and what requireAuthentication and isAuthenitcated do versus the lack of the whole new SASL/auth API/impl in proton-j at this point in time, possibly days before release, which seems to be needed in order to make them actually work the way they do in proton-c. If all we do now is change the default behaviour a little now in a way that requries most people to update their existing usage, knowing we will change the same bits again in bigger way that will require most people to update their already-updated usage again, then I'd prefer we didnt change the default behaviour now as the near term reward doesnt seem that great for all the ongoing hassle from the repeated changes, thats all I was meaning.
