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

Re: authz problem: mixing anon access + protected directory.

From: Omry Yadan <omry_at_yadan.net>
Date: Sun, 20 Jul 2008 21:10:42 +0300

BTW:

I don't fully agree with the statement :

"mod_dav_svn is just an apache module, and thus is forced to work with
apache's authentication design"

the only justification for mod_dav_svn is to service an svn repository
through apache.

if that requires deviating from the design a little - so be it.
(provided that it's possible without getting into the apache code - of
course).

Omry Yadan wrote:

> Ben,
>
> Thank you for the clarification.
>
>
> Ben Collins-Sussman wrote:
>
>> On Thu, Jul 17, 2008 at 8:47 AM, Omry Yadan <omry_at_yadan.net> wrote:
>>
>>
>>> What if the client sends the authentication credentials anyway (if
>>> they are
>>> available or if the user specifies them in the command line), and
>>> webdav is
>>> tweaked to authenticate the client in such case even if resource
>>> does not
>>> required authentication?
>>>
>>
>> There's no such thing as the client 'forcing' the server to
>> authenticate credentials. With apache, the server sends an
>> authentication challenge, the client responds to the challenge.
>> That's it. If the server doesn't send the challenge in the first
>> place, then no amount of client typing 'svn --username X --password Y'
>> is going to cause authentication to happen.
>>
>> The problem you're running into has been documented in the book for
>> years: see "Partial Readability" sidebar in
>> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.pathbasedauthz
>>
>>
>> As others have said, it's not something subversion can fix --
>> mod_dav_svn is just an apache module, and thus is forced to work with
>> apache's authentication design. There's nothing to 'look at' here;
>> we wrote the dav module and understand the problem completely, and
>> it's not a fixable thing. There are multiple workarounds that have
>> been offerred, however:
>>
>> 1. use http for anonymous, https for commits
>> 2. require authentication for all reads and writes, but announce a
>> generic 'guest' account with no password.
>> 3. have all your clients use the serf HTTP library instead of neon
>> 4. use svnserve instead of apache
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-20 20:11:07 CEST

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.