I'm filling in the list on an authentication architecture we'll be
using for upcoming M3. It's about as generalized as it can be.
Here are the parameters of the problem:
* The callers of any RA (Repository Access) library need to provide
a structure that represents who's doing the access. It's up to
the RA layer to actually *do* the authentication (and
authorization). It's up to the caller to provide the necessary
* If new RA schemas are written, or new RA layers are written, it's
inevitable that every top-level client in the world will need to
be tweaked and rebuilt to support them -- to *some* degree.
The issue here is that an RA library cannot directly prompt the
user for information -- like a password. So the top-level client
will need to "learn" about each RA library's authentication
needs. However, we'd like as little code churn as possible. For
example: if ra_foo needs information X to authenticate, and
somebody writes a new ra_bar module that needs the same
information, ra_bar should be able to make use of the fact that
the client-side libraries *already* know how to get it.
Here is what we're going to do:
* create a transparent svn_ra_user_t structure.
This structure contains the *union* of all authentication data
needed by all RA implementations. (There's no way around this.)
* all svn_client_*() routines now take a new argument: a 'hook'
routine from the command-line (or GUI) client.
* when svn_client_*() fetches an RA library appropriate to the URL
schema, it will get back a flag state. This flag-state indicates
which fields are needed within the user structure by the
particular RA library.
* libsvn_client now attempts to fill in every user_t field it can.
(for example, it can easily fill in a Unix UID field.)
* if libsvn_client can't fill in all the fields, it "kicks" the
user_t structure up to its client caller (using the hook routine)
and then the client finishes the job. (for example, prompting
the user for a password, reading a config file, etc.)
* the user_t object is now passed (along with the URL) to ra->open().
* the RA library does whatever authentication/authorization
it wants under the hood.
* the RA library (presumably) stashes the user_t object in
the "session baton" returned to libsvn_client.
* libsvn_client now goes on and uses the RA session baton as usual.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:33 2006