On 4/16/07, Josh Gilkerson <jwg@google.com> wrote:
> Latest patch. I am fairly certain that this is functioning properly.
>
> For configuration, I have overloaded the SVNPathAuthz. The values on
> and off and the default value(on) have retained their meaning, so
> configurations shouldn't be broken (Are there other apache will parse
> as on or off for a boolean option?). There is then another value,
> currently 'dangerous_direct', that indicates that mod_dav_svn should
> authorize directly to mod_authz_svn.
How about "short_circuit"? I think that this is a good name.
Please don't include the word "dangerous" in the option name as I find
the use of that word here to be confusing.
I haven't tested your patch yet, but, in general, your patch looks
very good. This new approach is much better than the approach that
Artem took on the artem-soc-work branch, because it requires so many
fewer changes.
I see a few spots where the formatting could be improved, but this is
minor and can be fixed at commit time if everyone is otherwise happy
with the patch.
On 4/16/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> > You also pointed out that "mod_authz_svn doesn't handle host-based
> > authorization at all." Are you implying that the new short circuit
> > authz option might break Apache's host-based authorization? If so,
> > how?
>
> Yes. Because you're only going to be using mod_authz_svn instead of
> permitting httpd to run through its normal authorization mechanisms -
> which include *all* authorization modules.
Isn't this fearmongering? Apache still runs through all of its normal
authorization mechanisms for the initial request -- the only
difference with "short circuit" authorization is that we don't
fabricate artificial subrequests to account for all of the internal
subversion repository paths which are referenced in a given report.
I do get your point, though, and I agree that "short circuit" is a
better name than "native", so I won't argue this point further.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 16 23:36:58 2007