Something that you might want to try, as an alternative to
mod_authz_svn, is using Apache's basic auth stuff with the LocationMatch
directive.
Using LocationMatch you can specify different permission schemes on a
per-repository basis (and even finer, although svn may not like that
particularly) and it should play fine with SVNParentPath. But adding a
new project is still going to require an 'apachectl graceful' I believe,
does that count as "bouncing"?
As an aside, can anyone explain the pros/cons of using mod_authz_svn
over doing the permissions/authentication using Apache and something
like LocationMatch?
Here's an httpd.conf snippet of what I'm talking about w.r.t. to a non
mod_authz_svn setup:
<LocationMatch "^/svn/repos/projA">
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /blah/passwd
AuthGroupFile /blah/group
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require group projA
</LimitExcept>
<Limit GET PROPFIND OPTIONS REPORT>
Require group projA
Require group projA_readers
</Limit>
</LocationMatch>
+ seth
On Wed, Oct 22, 2003 at 03:58:41PM -0500, Tess Snider wrote:
<snip>
> Some requirements:
> 1.) Per-repository authorization. The team on project A doesn't
> necessarily trust the team on project B (though the same user
> may be in both project A and project B).
>
> 2.) Per-repository permissions. User X may have RW access to project A
> but only R access to project B. Project C may be world-readable.
>
> 3.) Maximum stability. I shouldn't, realistically, bounce the webserver
> every time a new project is added.
>
> SVNParentPath appears to solve #3, and mod_authz_svn addresses #1 and #2,
> but if they won't play nicely with each other, I'm still in a pickle.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 23 02:43:37 2003