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

RE: Fine grained access control over ra_dav using... mod_authz_svn

From: Sander Striker <striker_at_apache.org>
Date: 2003-06-11 15:20:09 CEST

> From: John Locke [mailto:mail@freelock.com]
> Sent: Wednesday, June 11, 2003 12:33 AM

> Sander,
>
> Thank you thank you thank you!
>
> This is sweet, and means I can set up Subversion to work really well in
> my business...
>
> One question: if I use an AuthGroupFile, will this module recognize the
> groups defined in it, or do all groups have to be defined in the SVN
> Access File?

They have to be defined in the access file.

> (can you depend on the authorization module to define
> groups, and leave them out of this config?)

Unfortunately, because of the current way the auth hooks work and
are called in httpd, you cannot have one module implement group membership
and let another benefit from it. This will probably change in some
future version of httpd (read: whenever one of us has time to implement it).

> And a comment: +1 on reloading the config on each request (or at least
> leaving this as an option)...

The lack of caching will kill performance (I think).

> I would very much like to be able to update particular access files
> without restarting Apache.

But you will still be able to do that. There are three options, one being
discussed:

 - load the access file per connection instead of per request
 - load the access file at startup time and reload when the timestamp changes
   (requires locking)
 - load the access file at startup and require a (graceful) restart when
   someone changes it.

> Perhaps, if this becomes a performance hit, make this a configurable option--but
> otherwise, I like the idea of having this read like .htaccess files, at
> request time rather than startup. If there's another option, I'm all
> ears.

See above ;) Just for the record: in no event do I wish to make reloading
behaviour configurable.

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 11 15:21:00 2003

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.