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

Re: How to authenticate HTTP users when root dir also has anonymous access?

From: <kmradke_at_rockwellcollins.com>
Date: 2007-10-30 14:52:31 CET

dglasser@gmail.com wrote on 10/29/2007 08:52:11 PM:
> On 10/29/07, Christian Convey <christian.convey@gmail.com> wrote:
> > ...
> >
> > The problem is, if I enable this rule in my access control file:
> >
> > [my-repos:/]
> > @admin = rw
> > @developers = rw
> > * = r
> >
> > then Subversion/DAV seem to totally ignore the fact that the user was
> > willing and able to provide developers' credentials on the "svn co"
> > command line. I.e.:
> >
> > svn co --username cconvey --password mypasswd --no-auth-cache
> > http://localhost/svn/my-repos/
> >
> > Does anyone know how I can accomplish what I'm trying to do? (It
> > would need to work ideally on with svn 1.4.3 and 1.4.4)
> One possibility is to provide two different URLs accessing the same
> repository, one of which allows anonymous access and the other of
> which doesn't; then have your developers just use the latter.

I propose a "new" special character that means "all authenticated users":
(I use "&" as an example, I have done no investigation if it has other
 meanings in this context)

@admin = rw
@developers = rw
& = r

We ran into the same problem because we authenticate with LDAP. We wanted
everyone in the group to have read-only access, with restrictions farther
down. We were forced to duplicate our ldap group info in the access
file (300+ usernames). I realize we could setup cron jobs to sync group
but I felt that was too messy, due to the lack of some type of #include
in the access file format.

Has anyone else wanted some type of include capability in the access file
as well?
(And yes, I could have created my own input file format, and processed it
 the cron job, but that again feels messy.)

Kevin Radke
Received on Tue Oct 30 14:52:56 2007

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.