Re: authentication storage question

Dale Thatcher <subversion@dalethatcher.com> writes:

> I've been trying to find a decent place for the proxy callbacks
> without any major change to the svn_ra.h.

Look at the new svn_ra.h -- it might be better for you now.

Here's the new system, as simply as I can put it:

  * an administrator configures the svn server (apache) to require
    certain types of authentication for certain repositories.

  * the svn client attempts to do something (checkout, commit, etc.)

     * libsvn_client creates a table of callbacks that are able to
       provide auth information; it passes this table to neon.

     * if neon is never challenged by apache:

          the callback table is ignored.

     * if neon -is- challenged by apache:

          neon uses the callback table to "pull" authentication data
          from the client. (username, password, private key, cert,
          etc.)

          - if authentication fails, neon returns an error immediately
            to the client app.

          - if authentication succeeds, the svn subcommand finishes,
            and neon "cleans up" by invoking a client callback to
            cache the auth info in the working copy.

So really, the old system made some erroneous assumptions -- it
assumed that the client was in control. It assumed that the client
could wily-nily select any old authentication protocol from a menu of
choices. It can't.

Really, apache is in total control. Apache dictates exactly what auth
protocol will be used, end of story.

To make Subversion use a new authentication protocol called "FooAuth",
here's what would have to happen:

   * make sure apache understands the protocol, and can issue a
     FooAuth challenge when necessary

   * make sure neon knows how to respond to a FooAuth challenge

   * make sure libsvn_client knows how to provide the specific FooAuth
     information to neon, so that neon can properly respond.

---------------------------------------------------------------------
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