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