[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: auth question

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-02-19 15:04:38 CET

Scott Lenser <slenser@gs104.sp.cs.cmu.edu> writes:

> I'm currently trying to figure out what authentication options are
> available.

Authentication is completely determined by Apache. On the client
side, neon sends an HTTP request. Then Apache sends an authentication
challenge of some kind; neon then uses callbacks to fetch the
necessary information (username, password, etc.) to satisfy the
challenge.

Right now, the svn client libraries are capable of fetching a username
and password for neon. (See svn_ra.h for the section labeled
"Authentication".) To add new protocols, we'll need to write a new
'authenticator' callback table in there. (And make sure neon
understands the protocol, and that the client can provide the data.)

> I set up basic auth with a username and password, but find it
> kind of irritating to randomly (well, random to me) be asked for the
> username and password occasionally.

When the client provides a username/password to neon, and neon
successfully authenticates, the info is cached (recursively) in
.svn/auth/. So if you, say, commit from the very top of your working
copy, you'll only have to enter your password exactly once, and then
never again.

> [...] without random people having access to the repository (parts
> of code are under NDA). Can this be done with Apache?

Well, you certainly don't have to put password protection on write
requests only; that just happens to be our example in the docs. But
you can read-protect the repository as well by limiting GET and
PROPFIND requests.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.