> but the die has been cast; HTTP servers find the access control file
> using HTTP configuration, and we can't reasonably change that.
Okay. Would it be interesting to work in in a hybrid solution, with a
standard way to locate the ACL file for a repository, but give the httpd
and svnserve a way to override it?
Do this by keeping the interface I gave, but adding a function that
takes an svn_repos_t and returns the path to the standard ACL file. That
way, RA servers can either use the override path if it is given, or
locate the standard path and open that otherwise.
Wether this is interesting depends on if we want the location of the ACL
file to be standardised, eventually, even if this means going through a
transition.
> file is going to be different for different repositories, and that we
> already read svnserve.conf once per client connection.
Okay, I'll go with that. I was still reasoning in the perspective of my
setup, which has an http SVNParentPath and a common ACL file for all
repositories.
> I think you mean mod_authz_svn here.
Oops, yes. s/mod_dav_svn/mod_authz_svn/ where appropriate. I shouldn't
be touching mod_dav_svn.
> No documentation of required_access and granted_access, and I'd think
> those should be enums, not bare ints. (I believe it's our style to use
> enums rather than ints and #defines.)
It is the policy afaik. I'll correct the prototype for my first patch.
Should the possible values be documented in the function prototype or at
the enum definition, or both?
> I think you mean mod_authz_svn here.
See above. My bad.
> svnserve handles much larger-grain operations than mod_dav_svn, so
> caching the authz file for the lifetime of a connection should yield
> acceptable performance.
Okay, I'll go with that.
> One option would be to look at the authz file at the beginning of the
> checkout and say "Aha! I see a path entry for trunk/foo/bar, which is
> read-protected. I bet I will run into that at some point during the
> checkout. I'd better challenge the client for authentication now."
> However, this can't really work if there's wildcard support in the authz
> file.
I see. Thanks for clearing that up. So, do people want wildcard support
or "intelligent" challenge support?
> I think most of the slowness comes from HTTP overhead, and not the
> actual lookup. I'd wait until someone measures a performance problem
> before worrying about this.
Okay.
> The authz code doesn't have to *parse* anything to answer the question;
> the authz file was loaded and parsed into a nested set of hashes at
> connection initiation time. I think if you're not careful, you'll wind
> up designing a cache which is precisely as slow as the libsvn_repos
> function you'd be calling on a cache miss.
Good point. If the parsing already works the file's contents into hashes
that are sufficiently optimal, no point in repeating the structure at a
higher level. Anyhow, I'll start with getting the actual authz in there.
Optimizations and stuff can wait until then.
I'll update my wiki page to sync it with this reply. If there are no
other comments/objections, can I consider this tentatively approved and
start implementing?
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 22:52:55 2005