Thanks for the reply Ben, I think I get it now.
SVN_AUTH_CRED_USERNAME is only used by ra_local, which wasn't clear in the
doco.
And svnserve requires SVN_AUTH_CRED_SIMPLE because it applies the retrieved
values against its password-db, right? NB it appears I wasn't getting the
callbacks for SVN_AUTH_CRED_SIMPLE because I had chosen not to define a
password-db.
> 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.
Then this is indeed bad news. Sounds like I'll have to switch to ra_local
ahead of time, which will crimp testing of this component in isolation. I
just don't want to have to replicate a map of a users/passwords within SVN.
In asnwer to your question about what would have already performed the
authentication - a web server.
But I do need to indicate to SVN who the caller is.
Do all instances of svnserver require a password-db to have been configured?
What about a tunnelling call to svnserve via "svnserver -t"?
Surely the SVN password-db isn't expected to contain all operating system
users and their passwords?
It kind of feels like there's a piece of server-side authentication that is
not being exposed. At the moment that piece is hardcoded to use the
password-db for svnserve, and hardcoded to just accept the username for
ra_local. Its a shame that the server-side choice is not configurable other
than by switching between protocols.
William
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 3 06:06:06 2005