On Fri, Jan 05, 2007 at 01:23:09AM +0200, Vlad Georgescu wrote:
> >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.
>
The situation I was thinking of was one where someone had deliberately
removed or disabled the CRAM-MD5 plugin to force use of a particular
type of authentication. As I understood it, we currently don't care
what SASL plugins are available, and so we can use whatever is
available. Refusing to use a particular plugin simply because it's not
CRAM-MD5 seemed like a bad idea to me.
> >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.
>
Yup, if you can achieve that, it sounds like an ideal solution. I'll be
able to build again without needing to use --without-sasl, excellent!
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Fri Jan 5 00:31:03 2007