Vlad Georgescu wrote:
> Properly implementing SASL support in Subversion will require some
> refactoring:
>
> * On the client side:
> Authentication is performed by the following functions in
> subversion/libsvn_ra_svn/client.c : find_mech, auth_response,
> read_success, do_auth. (There's also handle_auth_request, but it only
> checks to see if the mechansm list is non-empty and then calls
> do_auth).
>
> Basically I want to extract these functions from client.c and put them
> in another file (say, "old_auth.c"). The entry point for
> authentication would be do_auth. I would then create a new file
> "sasl_auth.c" that also exports do_auth but does authentication
> through Cyrus SASL.
>
> The idea is to conditionally compile and link only one of those files
> depending on whether or not SASL is present on the system.
OK, sounds fairly reasonable.
A question (same one as Daniel and Branko): Is there really absolutely
no circumstance in which we would want the existing code, when compiled
to use SASL?
Please name the file something like 'trivial_auth.c' - *not* old,
because it is never going to go away, because we do not want to
institute a hard requirement on a SASL library.
Lastly, one piece of advice - altering the build system to support
conditional compilation and linking of files is likely to be more
trouble than it is worth. Just use #ifdefs - even if you end up
surrounding the entire content of a file in them.
> * On the server side:
> The relevant file here is subversion/svnserve/serve.c. We still want
> to put the old auth functions in another file, and create a new file
> for SASL. However, since we want to default to NOT using Cyrus SASL
> (because it's more difficult to configure) we will use both files. To
> enable SASL, we should use an option in svnserve.conf (something like
> "auth-type = sasl")
>
> There's also the question of what to do with libsvn_ra_svn/cram.c.
> This file contains the CRAM-MD5 authentication functions that should
> probably go in the "old_auth.c" files, but also some utility functions
> such as hex_decode and hex_encode that I still need to use in my
> implementation.
Leave the CRAM-MD5 stuff in cram.c, I think.
As a first step, make the functions in cram.c that you need in other
files visible throughout libsvn_ra_svn (non-static, appropriate name
prefix, declared in library-local header file).
Then, moving them to a more appropriately named file can be done as a
separate change.
Max.
Received on Mon Jun 5 12:06:53 2006