A related (not identical) issue is https://issues.apache.org/jira/browse/DISPATCH-244 Andrews fix will fix that problem as well as the failures discussed here. Installing config files will not, nor will it help with developers trying out examples in a source build etc.
I agree that this is not an issue for a properly configured production system, and there are easy workarounds (make sure your laptop has a dotted name, always specify mechs=ANONYMOUS for examples and tests etc.) but given the way the problem shows maddeningly in some situations but usually not, it could easily frustrate developers to the point that they throw proton away before they find the workarounds. It took me 2 weeks to figure out that dispatch tests would run 10x faster if I turned off my VPN, and more weeks to realize I needed to use saslMechs=ANONYMOUS everywhere. I think another month before Chuck discovered that calling your machine "bob.localdomain" instead of "bob" also fixed the problem. For developers who initially don't care about security and expect things to Just Work with default config, I think this issue may be losing us developers. Cheers, Alan. On Tue, Jun 19, 2018 at 11:01 AM, Gordon Sim <g...@redhat.com> wrote: > On 19/06/18 15:39, Andrew Stitcher wrote: > >> Thanks everyone for their thoughts: >> >> I've considered the feedback, especially Gordon's point that the server >> mechanisms are already configured using the SASL configuration file >> which you need in any case to set up the authenticatino db. >> >> I think the issue is still enough of a speed bump to new developers >> that I've decided to go ahead and make this a purely client side >> filter. >> > > Can you elaborate a little on that? Would installing a default sasl config > along with the library not address those cases? > > In this case there won't be any confusion over proton opaquely >> changing the mech list from what the SASL config file lists. I've gone >> with with the simplest no extra API option - this can certainly change >> is it turns out to be a problem. >> >> The new PR is in the same place [1] and I'll merge this soon unless >> there are serious objections. >> > > I think it is the wrong solution. > > I don't imagine it will affect all that many people though, so if you are > determined I won't stand in the way. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
