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

Re: LDAP and LIMIT params in Locations

From: Brian Brophy <brianmbrophy_at_gmail.com>
Date: Fri, 23 Jan 2009 06:07:17 -0500

In prior experiments on the 1.3 baseline, I seem to recall that if you
use Apache's LIMIT to accomplish authorization without using the
subversion authorization file (of groups, and locations where groups
have read, read/write, etc) that the security worked as expected. For
example, members of group were properly restricted to their expected
operations (as configured in Apache). However, the svn log result did
not have the author field populated with the username because svn was no
longer doing authorization.

I will admit I have not played with this on a more recent baseline, but
you may wish to explore the two and how they affect resulting svn log
messages if maintaining the author field data is of value.

Brian

kmradke_at_rockwellcollins.com wrote:
>
> Subversion uses "GET", "PROPFIND", "OPTIONS", and "REPORT" in doing
> read operations
> and other HTTP commands when doing write operations. Apache handles
> those commands
> and forwards them to svn after it validates you as an user has access
> to those commands.
>
> Kevin R.
>
>
> Oliver Marshall <oliver.marshall_at_g2support.com> wrote on 01/21/2009
> 10:16:29 AM:
>
> > Ahh cheers. So the “GET”, “PROPFIND” etc are Apache oriented rather
> than
> > specific to SVN itself?
> >
> > Great.
> >
> > From: kmradke_at_rockwellcollins.com [mailto:kmradke_at_rockwellcollins.com]
> > Sent: 21 January 2009 16:00
> > To: Oliver Marshall
> > Cc: users_at_subversion.tigris.org
> > Subject: Re: LDAP and LIMIT params in Locations
> >
> >
> > The limit/limitexcept sections allow you to have separate read/only and
> > read/write groups.
> >
> > For example (Group xxx has read/write access, Group yyy only has
> read access):
> >
> > # These groups have write access
> > <LimitExcept GET PROPFIND OPTIONS REPORT>
> > Require ldap-group CN=xxx,OU=Groups,DC=company,DC=com
> > </LimitExcept>
> >
> > # These groups have read access
> > <Limit GET PROPFIND OPTIONS REPORT>
> > Require ldap-group CN=xxx,OU=Groups,DC=company,DC=com
> > Require ldap-group CN=yyy,OU=Groups,DC=company,DC=com
> > </Limit>
> >
> > The apache docs have more detailed info. (This is really an apache
> related question,
> > and has nothing to do with Subversion itself.)
> >
> > Kevin R.
> >
> > Oliver Marshall <oliver.marshall_at_g2support.com> wrote on 01/21/2009
> 06:55:26 AM:
> >
> > > Hi chaps,
> > >
> > > I’ve got SVN working with LDAP on Apache so that users are
> authenticated
> > > against the Windows server here. However I do have a question.
> > >
> > > In lots of examples I see something like this;
> > >
> > > <location /svn>
> > >
> > > <limit this that the-other>
> > > LDAP AUTH HERE
> > > </limit>
> > >
> > > </location>
> > >
> > >
> > > Now, I’m not using a LIMIT parameter in my dav_svn.conf file. I
> just have the
> > > locations with the LDAP stuff and requirements under each one.
> > >
> > > Should I be using the LIMIT param at all? Does it bring anything
> to the party?
> > >
> > > Olly
> > >
> > > --
> > > Important notice:
> > > We have moved offices. Our new address is below.
> > >
> > > G2 Support
> > > Network Support : Online Backups : Server Management
> > >
> > > Tel: 0870 904 3443
> > > Email: oliver.marshall_at_g2support.com
> > > Web: http://www.g2support.com
> > > Mail: 2nd Floor, 130a Western Rd, Brighton, Sussex, BN12LA
> > >
> > > G2 Support LLP is registered at Mill House, 103 Holmes Avenue, HOVE
> > > BN3 7LE. Our registered company number is OC316341.
> > >
> > >
> > >

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1044670

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-23 12:07:54 CET

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

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