Re: Thoughts on libsvn_auth

On Wed, Apr 02, 2003 at 02:05:09PM -0600, Ben Collins-Sussman wrote:
>...
> Let's allow each RA layer to create its own opaque 'realmstring'. The
> string could be any combination of UUID, URL, description, etc. It
> might vary not only by RA layer, but also based on the type of
> challenge received, and how much information is available at the time
> of challenge. It's completely up to an RA layer to decide how to
> create a unique realmstring based on the circumstances.
>
> Either way, svn_auth_first_creds() now takes a const char *realmstring
> argument. Providers treat the string as an opaque blob, and use it to
> differentiate one set of credentials from another.

To be concrete, my suggestion would be:

  ra_local -- use the path, or possibly the UUID(*)
  ra_dav -- use a string "HOST/REALM" where we've parsed HOST out of the
              URL, and REALM is provided by the Neon callback
  ra_svn -- ???

(*) UUID might not be nice if we display this string to the user during a
prompt. The ra_dav string is reasonable to display directly, as the REALM is
already what people see inside browsers' auth dialogs.

One of the neat things here is that the key for the auth data will match
what the server administrator has set up. It isn't keyed by the repository
you contact, but by the realm the admin defined. In many cases, that realm
might be common across the entire server (because the server might only have
a single user/pass database). This implies that aggregating repositories
from a single server would not necessarily ask you over and over for auth
information once you first provide credentials for that realm.

For example, tigris.org has a common user/pass defined across the entire
server. You would only need to provide your tigris.org credentials *once*
(and have them cached), and then you can access every repository on the
server. No need to provide them for every project's repository(!).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org