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.

>  Given the older SASL
> API means much of the SASL work including mechansim selection happens
> outside/before proton-j and you get as far as making a connection,
> isnt that going to be a bit of a pain to implement and use?

Well I obviously disagree, else I would have implemented the C SASL
support like this!

TBH, I think that using the same API in Java would make sense along with
an extra "plugin API" to allow implementing mechanisms (assuming there
is no external Java library like Cyrus SASL that can do the work for
us).

But yes that is new work, probably not going to happen before Proton
0.11.
> 

> Might it be simpler to use allowSkip() until such time the wider SASL
> API is actually implemented, keep the default behaviour as it was
> previously (so people will be less likely to need to use the behaviour
> toggle and less likely to care what it is called), and update
> whichever reactor tests that needed the change to configure it that
> way in the meantime?

I'm agnostic on this point really, I'd just like to ensure that the C
and Java APIs actually converge in the shortest time scale. The
alternative would be to stop testing them with the same test code -
there are already far too many specific tests for Java or Windows in the
tests.

Andrew


Reply via email to