On 19/06/18 21:05, Andrew Stitcher wrote:
On Tue, 2018-06-19 at 19:32 +0100, Gordon Sim wrote:
On 19/06/18 19:25, Alan Conway wrote:
What do you think the default
server configuration should be? Should we default to excluding the
offending mechs on the server side by default?
To my mind the entire point of this change is that it will work
irrespective of the server end and how it is configured. >
If the server is configured not to offer the 'offending' mechanisms
then everything will be fine in any case, but if the server has no
config or is misconfigured for some reason thenthis change will either
work (using a supported mechanism/anonymous) or fail during
authentication rather than before responding to the servers mechanisms
offer.
I do think perhaps the error handling/communication on the client side
could be better in proton.
With qpid::messaging you get an error that while not exactly clear at
least indicates that the issue is with GSSAPI; the proton examples just
exit with no message at all.
To my mind, the question is whether making GSSAPI mechanisms opt in at
the client end is more surprising than having them trip you up when you
aren't even aware they could be a problem.
Gordon, do you think that is the case?
I think having some mechanisms filtered out from what the broker is
offering is surprising. This is only likely to affect users who want
GSSAPI of course, which is a minority. It is a potentially breaking
change though.
I do *also* think running one of the server examples that has sasl
enabled (since that is the default and we have not explicitly turned it
off) but not configured results in surprising behaviour (assuming the
gssapi plugin is installed). However I think it is these examples that
should be fixed. That way regardless of the 'amount' of surprise
associated in each case we end up with less overall. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
