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

Re: [RFC] Integrating Cyrus SASL into Subversion

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-06-05 14:52:23 CEST

Branko Čibej wrote:
> Vlad Georgescu wrote:
>> On 6/5/06, Daniel Berlin <dberlin@dberlin.org> wrote:
>>> 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.
>>> Uh, normally we just create an interface and have both implement it, so
>>> that conditional compilation only changes whether we have a given
>>> interface provider available.
>>>
>>> Then you can just choose from the available ones at runtime.
>> I agree with this on the server-side, but on the client-side I can't
>> think of a reason why you would ever use the old code over the SASL
>> implementation, if SASL is available.
> Do the SASL mechanisms completely (functionally and semantically)
> replace the auth methods we have in place now? E.g., what happens if the
> client is built (as you suggest) to only use SASL, but talks to an older
> server that doesn't use SASL?

Right, this is one of the situations i am thinking of.
If the SASL code completely subsumes the old code in all situations,
then feel free to do something like you suggest.
If not, it should really be selected at runtime.

>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 5 14:52:54 2006

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