On Wed, Oct 11, 2006 at 01:59:04PM +0300, Vlad Georgescu wrote:
> If a SASL mechanism fails sufficiently early (i.e. before the client
> sends the initial response), don't automatically fail the
> authentication. Instead, fall back to the next best mechanism sent by
> the server.
I'm also having a problem with the SASL-enabled svnserve - and while it's
not completely identical to the problem you're fixing here, I suspect
it's in the same area.
The problem I have is that if I link to the SASL libraries (which happens
by default), I can no longer establish a non-SASL connection. That is,
there appears to be no fallback from the SASL negotiation to the non-SASL
negotiation (of anonymous, cram-md5).
Specifically, I get the following error:
$ basic_tests.py --url=svn://localhost:3691 1
svn: SASL(-4): no mechanism available: No worthy mechs found
FAIL: basic_tests.py 1: basic checkout of a wc
Which, arguably, is correct, as I have no configured SASL mechanisms
that can be used by the client to prove the user's identity to the server.
[Incidentally, I presume that these are done on a per-service basis or
similar? We're not going to ship in a mode that suddenly allows every
valid account in /etc/passwd to commit to a repository, are we?]
Anyway, the current situation is a not a good user experience, especially
as I have no reason to enable SASL myself (though I _do_ need the SASL
libraries to be installed for some other applications).
Can we not fall back to the previous authentication mechanism if SASL
doesn't have any matching authentication mechanisms?
Received on Wed Oct 11 14:53:40 2006
- application/pgp-signature attachment: stored