[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SASL auth failure, reported by Cyrus SASL as "no mechanism available"

From: Vlad Georgescu <vgeorgescu_at_gmail.com>
Date: 2007-01-05 00:23:09 CET

On 1/5/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Thu, Jan 04, 2007 at 11:56:16AM -0800, Daniel Rall wrote:
> > If we compiled both sasl_auth.c and simple_auth.c, could we
> > interrogate the installed Cyrus SASL plug-ins at Subversion library
> > initialization time, and fall back to simple_auth.c if both the
> > ANONYMOUS and CRAM-MD5 plug-ins aren't available?
> Whoa, wait a sec. The whole point of SASL is pluggable auth - I
> wouldn't want us to be making a policy decision (to fall back on
> svn-native auth) based on the presence or absence of particularly-named
> SASL auth modules.(Unless those are the only two we can use? But I
> didn't think that was the case).

True, but if a client doesn't even have ANONYMOUS or CRAM-MD5, it's
even less likely to have one of the more advanced plugins. Daniel
suggested a simple way to guarantee backward compatibility when these
mechs aren't present.

> I'd prefer that we attempted SASL auth and failed back to native auth
> only if that fails to find a matching mech. (I'm not sure, but it's
> likely that that would require us to drop the connection and reconnect,
> right?)

That's what I wanted to do initially, and I agree it's the best
approach. It wouldn't require us to reconnect, but it wouldn't quite
work because we currently fetch user credentials before selecting the
mechanism (in a sense, we're trying to 'push' credentials, instead of
pulling them when needed). So if we retry authentication with
simple_auth, we would lose the first set of credentials.

So how about this: I'll work on changing the SASL code to use
callbacks for credentials (like ra_dav/neon), and then we can
implement this like you suggested, by falling back to simple_auth.c
only when SASL can't find a matching mech.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 5 00:23:20 2007

This is an archived mail posted to the Subversion Dev mailing list.