Greg Stein gstein@lyra.org writes:
On Fri, Jan 24, 2003 at 12:05:34PM -0600, Ben Collins-Sussman wrote:
Justin Erenkrantz jerenkrantz@apache.org writes:
--On Friday, January 24, 2003 11:47 AM -0600 Ben Collins-Sussman
...
sussman@collab.net wrote:
Actually, gstein and I discussed the fact that every type of
authentication output structure (like our existing
svn_auth_cred_simple_t) might need to be coupled with an equally
specific input structure as well. I guess the first_ and
next_creds function would take the input structure as a void *.
Should I just implement that now?
Let's accumulate more information and figure out the right answer. The set
of information might be quite varied. For example, with Basic auth, there is
a realm that you're authenticating with. It is quite reasonable to assume
that a provider will key the credentials off the realm.
So we've got the UUID, maybe the Basic (and Digest?) realm, and who knows
what else.
Actually, I'm in process of writing a provider that looks in
.svn/auth/ for username and password. (I'm mostly ganking code from
libsvn_client/auth.c.) But in this example, the provider needs the
name of the directory to get/set from. Here's the public API:
/** Set @a *provider and @ *provider_baton to an authentication
provider of type @c svn_auth_cred_simple_t that gets/sets
information from a working copy directory @a wc_dir. If an access
baton for @a wc_dir is already open and available, pass it in @a
wc_dir_access, else pass NULL. */
void svn_auth_get_simple_wc_provider (const svn_auth_provider_t **provider,
void **provider_baton,
const char *wc_dir,
svn_wc_adm_access_t *wc_dir_access,
apr_pool_t *pool);
So I don't think that we need to pass input structures: the public
functions for retrieving providers will each have their own relevant
input requirements. For example, when we have a provider that fetches
data from ~/.subversion/, a GUID will be required by the public API.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:15:35 2006