authentication re-vamp

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)

Wishlist
========

  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