On Jun 2, 2005, at 8:37 PM, William Ferguson wrote:
>
> 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.
That credential type is *only* used by ra_local. svnserve and apache
both demand credentials of type SVN_AUTH_CRED_SIMPLE, which is a
{username, password} pair. You can't change that.
> Do i necessarily need to supply a provider that
> returns credentials that contain username and password? What does
> SVN do
> with the password?
svnserve will not work unless you load a provider capable of
providing 'simple' creds.
>
> 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.
That's because there were no 'simple' providers available, so it
failed instantly.
>
> 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?
I don't understand what you're trying to do...
>
>
> 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
"Already performed"? By who? Where? What? When?
> (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.
If you configure svnserve to require authentication, it will send a
challenge that demands a simple credentials structure. It's that
simple.
It sounds to me like
(1) you don't want svnserve to require a password
(2) you *do* want svnserve to have a username available to use as
commit-author, etc.
If that's the case, you're out of luck. There's no way to do that.
Either the server has an *authenticated* username (i.e. a name/
password pair), or no username at all. There's nothing in between.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 04:27:25 2005