-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38863/#review101119
-----------------------------------------------------------

Ship it!


I think this patch is the appropriate change. It makes most sense to have SASL 
enabled by default (even if it is not always needed). I think that in every 
case where it isn't actually useful (ANONYMOUS and EXTERNAL mechanisms) it 
isn't harmful either.

I think it makes sense to be able to disable SASL although as above I can't 
think of a case where it really matters unless the peer doesn't support it.

I like the key word argument change.

- Andrew Stitcher


On Sept. 29, 2015, 9:56 p.m., Gordon Sim wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38863/
> -----------------------------------------------------------
> 
> (Updated Sept. 29, 2015, 9:56 p.m.)
> 
> 
> Review request for qpid, Justin Ross and Ted Ross.
> 
> 
> Bugs: PROTON-1008
>     https://issues.apache.org/jira/browse/PROTON-1008
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> -------
> 
> There is no direct and easy way to control whether a sasl layer is used or 
> not that works for all cases. Prior to the 0.10 release, specifying a 
> username was the trigger to enable sasl. However for EXTERNAL or GSSAPI that 
> doesn't work as well. This patch proposes adding an explicit toggle to either 
> enable or disable the use of sasl. It is enabled by default (ANONYMOUS is 
> then a simple way of avoiding actual authentication if not needed), but can 
> be disabled at the container- or connection- level.
> 
> For consistency I've also allowec connection level overrding of the 
> allowed_mechs and allow_insecure_mechs options.
> 
> 
> Diffs
> -----
> 
>   proton-c/bindings/python/proton/reactor.py 8de5d89 
> 
> Diff: https://reviews.apache.org/r/38863/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Reply via email to