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

Re: Thoughts on libsvn_auth

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-04-02 21:13:57 CEST

Manoj Kasichainula <manoj@collab.net> writes:

> Hi. This is my first post to the list in about 2.5 years. As a sort of
> reintroduction, I'm Manoj, and I work at CollabNet along with many
> others on this list. Some people here will know me from my past work
> on Apache.
>
> With some help, I've been learning the svn-client authentication
> API, and I have some comments and questions on it.

Sorry it took me so long to respond, Manoj. Here are my thoughts
about your nice, long set of questions and suggestions.

- Manoj is concerned about scoping/realm of credentials.

  The idea of a credential's 'space' or 'realm' should be a runtime
  parameter used by providers... i.e. live in that auth_baton hash
  thingy.

  For example, say you have a provider whose job to fetch and store a
  cred_kind of type {username, password}. The svn server issues an
  authentication challenge for realm "foo". The code which receives
  this challenge

     - places the realm into the the auth_baton's runtime param hash
     - calls svn_auth_first_creds()

  The provider looks for the realm in the hash, so it knows which set
  of creds to retrieve from disk, or which realm to display at a user
  prompt. It also uses the hash-value to decide how/where to store
  the creds later on.

  This is a classic example of why we have the runtime parameter hash
  in the first place. There are certain pieces of information which
  providers don't have at startup time; they're part of the actual
  auth challenge.
  
  As jerenkrantz said, another runtime parameter is the repository's
  UUID. However, because we want this parameter available to *every*
  provider in the universe, we'll probably forcably pass it into
  svn_auth_first_credentials() rather than pass it "implicitly"
  through the hash, once we fix ra_dav's chicken-and-egg problem.

  Philip has pointed out as well that a 'realm' may actually be more
  than just a UUID -- but perhaps a URL as well.

  I'm imagining this solution: we declare an 'auth_realm' structure in
  svn_auth.h which contains {UUID, URL, description_string}. The
  caller of svn_auth.h routines can create one of these, fill in
  whatever information it has at the time of the challenge, and pass
  the structure directly into svn_auth_first_creds(). Providers can
  make use of whatever info is available.

- Manoj wants finer-grained 'storage' abilities: save to disk, cache,
  etc. Rename to 'save_creds' to 'credentials accepted'?

  Jerenkrantz likes the rename. Sounds good to me.

- Manoj doesn't think providers are very sharable.

  Well, certainly not ones that use OS-specific disk registries or
  caching facilities!

  But the very simple ones we have in libsvn_client *could* be used by
  stock svn clients: they read either basic-auth or cert data from
  within .svn/ or ~/.subversion/ areas, and know how to prompt. If
  I'm writing a client, it's probably useful to have these providers
  available to me. If I want to get fancy, I can write my own.

- Manoj suggests breadth-first retries instead of depth-first?

  Ick... I agree with jerenkrantz. If the application placed provider
  A before provider B, that means it thinks provider A is more
  important... It makes no sense to try A, then B, then A again, then
  B again, etc. The whole point of 'ordering' providers is to allow
  prioritization.

- Manoj wonders if all looping should an optional thing anyway..?

  The code receiving the auth challenge is deep within a shared
  libsvn_ library; it can't know which providers are available, or
  which ones the application prefers. That's why we have this whole
  auth_baton abstraction. The looping is a fundamental part of that
  abstraction.

- General problem pointed out by philip: svn_auth functions require a
  UUID, doesn't the auth challenge happen before a UUID is available?

  ra_local and ra_svn are fine, they get the UUID when RA->open() is
  first called. I've already proposed a fix for ra_dav in another
  mail.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 21:14:57 2003

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