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

authentication re-vamp

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-09-14 00:06:25 CEST

Gee, like we need another huge discussion. :-)

There's a laundry list of things to do re: rewriting the way we do
authentication on the client-side. (IOW, deciding how the RA
libraries, libsvn_client, and the client app all work together to
authenticate against a server.)

I've rewritten the issues listed in bug #456 below. All of them are
very easy to do, except for the last two. I specifically need to ask
Greg how the heck things are working, or how they should work.

Greg, Joe, can you guys talk about the last two issues?


Subversion authentication system rewrite. (#456)


  A. new RA vtable sequence: put back open(). [EASY]

     RA->open (URL, callback, [...])

          ...callback can be a way of storing a tmp file in WC.

     authenticator = RA->get_authenticator(method)
     session_baton = svn_client_authenticate(authenticator)
          ... drives the authenticator object.

  B. RA session opened by app, not in libsvn_client. [EASY]

     Have [cmdline/main.c] open the RA session, and all of the
     svn_client_ routines *take* an authenticated session_baton.

     This will make things better for GUIs or shells, or anything that
     plans to execute more than one subcommand before exiting!

  C. Improve auth-method selection [EASY]

      -- auth-method as optional commandline switch

         Use a single switch that takes a string: e.g. --auth="ssl"
      -- else: keep trying all available methods until they all fail.
         Cache info from one attempt to the next if possible.

  D. Prompts [EASY]

      -- display the method being used
      -- display a 'default' username if available

      -- prompt callback should take an array of prompts

  E. Push vs. Pull models. [HARD]

     The current system pre-emptively requests info, then "pushes" it
     at the RA layer. This is odd, given that Apache typically makes
     a challenge and then "pulls" the info. As a result, the info is
     effectively being cached in the session_baton until Apache pulls
     it from there.
     So, it would be nice to switch the whole client/user-interface to
     work with the "pull" model too. One of the main benefits of this
     is that failed authenication can be detected *immediately*;
     right now failed authentication is simply ignored during
     checkout, and isn't discovered until a commit fails later on.
  F. Method negotiation? [HARD]

     Can the RA library (running client-side) 'discover' what methods
     are supported by the server?

     Ideally, this list of methods returned to the client should be
     dynamically discovered, rather than being a static list, as it is now.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.