Jan -- thanks for noticing this. I guess what you're saying makes
sense: if the svn apache server is going to deny LOCK/UNLOCK requests
no matter what, there's no point in sending auth challenges. Might as
well add them to the <LimitExcept> area.
Of course, if you're using 'SVNAutoversioning', you'd want to take
those commands back out again.
I'll add this to our book TODO list, thanks.
"J. Nijtmans" <Jan.Nijtmans@kadaster.nl> writes:
> When a subversion server receives a LOCK or UNLOCK request from
> a non-subversion client, the behavior is not always as expected.
> The problem described here is easy to be fixed in the apache
> configuration (it is not a Subversion bug!). I would like to
> share this information, so that it can be included in the
> documentation.
>
> In the documentation at:
> Subversion: The Definitive Guide
> Repository Administration
> Networking a Repository
> Repository Permissions
> Permissions, Authentication, and Authorization
> the last example says:
>
> <Location /svn>
> DAV svn
> SVNParentPath /usr/local/svn
> AuthType Basic
> AuthName "Subversion repository"
> AuthUserFile /path/to/users/file
> <LimitExcept GET PROPFIND OPTIONS REPORT>
> Require valid-user
> </LimitExcept>
> </Location>
>
> This is what I used for my repository. I checked in a Visio file
> in the Subversion repository, and gave it the right properties so
> that it would be recognised as such by Internet Explorer:
>
> svn add foo.vsd
> svn propset svn:mime-type application/vnd.visio foo.vsd
>
> When trying to open this file using Internet Explorer, it
> first asked for a username/password. No matter what password
> was entered, the file was opened correctly by Visio!
>
> The explanation for this is that Visio first tries to LOCK
> the file, in case it is getting the file from a WebDAV repository.
> If it fails, Vision assumes that the repository is not WebDAV
> aware, and continues to open the file normally. The Apache
> configuration requires a password for LOCK and UNLOCK, but
> those operations are not supported anyway. A little modification
> can fix this behavior (see example at end of this mail).
>
> Therefore I suggest to provide an addition example in the
> documentation, after the already mentioned example.
> The added text could be as follows:
> ---------------------------------------------------------------------
> This, however, has the undesired side-effect that clients attempting
> the LOCK or UNLOCK operations will be asked for a password. Even if
> a valid password is supplied, the operation will fail always because
> the LOCK and UNLOCK operations are not supported by Subversion. Therefore,
> a little improvement would be to let those operations fail always:
>
> <Location /svn>
> DAV svn
> SVNParentPath /usr/local/svn
> AuthType Basic
> AuthName "Subversion repository"
> AuthUserFile /path/to/users/file
> <LimitExcept GET PROPFIND OPTIONS REPORT LOCK UNLOCK>
> Require valid-user
> </LimitExcept>
> <Limit LOCK UNLOCK>
> Order deny, allow
> Deny from all
> </Limit>
> </Location>
>
> Regards,
> Jan Nijtmans
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 17 16:37:52 2003