Actually the single provider I had configured has a cred_kind of
SVN_AUTH_CRED_USERNAME and set the credentials to be an instance of
svn_auth_cred_username_t. Do i necessarily need to supply a provider that
returns credentials that contain username and password? What does SVN do
with the password?
But even though the SVN server was configured with
anon-access = none
auth-access = write
the provider's #first_credentials function is never called, which I don't
understand.
Am I on the right track?
What indicates to the authentication mechanism that the user has been
authenticated?
Is it a non NULL credentials object returned by
first_credentials/next_credentials?
Maybe I haven't explained this clearly enough.
I don't necessarily want the SVN server to authenticate anyone, as
authentication will already have been performed (and I will know the current
caller's identity). But I do want to indicate to the SVN server the identity
of the current caller so that it can note the author of commits, record lock
ownership, etc.
How should I indicate to SVN (using the RA layer) the identity of the
current caller?
Is using the SVN authentication mechanism the appropriate approach?
William
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Thursday, 2 June 2005 10:47 PM
To: William Ferguson
Cc: 'users@subversion.tigris.org'
Subject: Re: Authentication
On Jun 2, 2005, at 1:56 AM, William Ferguson wrote:
> // pack the providers into an array
> apr_array_header_t *providers;
> // add provider - probably just need one simple one that reads the
> usernmae
> form the params perhaps?
That's the problem. You've installed only 1 provider, the one which
sucks the {username, password} credential structure from the
parameter hash. So when the server challenges the client, the client
asks this one provider, which returns {username, NULL} -- because
there's no SVN_AUTH_PARAM_DEFAULT_PASSWORD sitting in the parameter
hash. And you get failure.
If you were to add other providers -- like ones that pull credentials
from the disk cache, or ones that prompt the user, then the client
would have more options for digging up the password.
Remember, the username doesn't exist in a vacuum. The server and
client operate on a {username, password} *pair*.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 02:09:33 2005