Hi,
Could someone reproduce the following bug? If confirmed, I like to add
it to the bug tracker.
Thanks!
Freek
Summary:
For webdav based repositories, "subversion checkout" does not fetch
restricted subfolders in a repository if the root folder is anonymously
accessible, even if proper authentication is given.
Steps to reproduce:
1. Set up Apache with SVN and webdav. I simply took a fresh Debian
install with the libapache2-svn packages (and relevant dependencies).
2. Set up a new repository with anonymously accessible root, and
restricted subfolder. E.g., with this configuration:
---- httpd.conf: ---------------------------------------------
ServerName www.example.com
<Location /svn>
DAV svn
SVNParentPath /var/data/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
order allow,deny
allow from all
Require valid-user
Satisfy Any
AuthzSVNAccessFile /etc/apache2/dav_svn.acl
</Location>
----------------------------------------------------------------
---- dav_svn.acl: --------------------------------------------
[myrepos:/]
auser = rw
* = r
[myrepos:/restrictedsubfolder]
auser = rw
* =
----------------------------------------------------------------
htpasswd -b /etc/apache2/dav_svn.passwd auser secret
3. Do a checkout as user "auser":
svn checkout --user auser --password secret \
http://www.example.com/svn/myrepos
Expected result:
I expect that the whole myrepos repository would be checkout out,
including the restrictedsubfolder, as that is readable by auser.
Actual result:
All of the repository is checked out as anonymous, and the
restrictedsubfolder is not downloaded.
Regression:
The commands and provided username/password are correct. In fact, here
is an excerpt form the Apache log file:
Anonymous checkout of root folder: OK (HTTP 207 result):
192.0.2.34 - - "PROPFIND /svn/myrepos HTTP/1.1" 207
665 "-" "SVN/1.4.0 (r21228) neon/0.25.5"
Anonymous checkout of restrictedsubfolder: Disallowed (HTTP 401 result):
192.0.2.34 - - "PROPFIND /svn/myrepos HTTP/1.1" 401
560 "-" "SVN/1.4.0 (r21228) neon/0.25.5"
Authenticated checkout of root folder: OK (HTTP 207 result):
192.0.2.34 - auser - "PROPFIND /svn/myrepos HTTP/1.1" 207
665 "-" "SVN/1.4.0 (r21228) neon/0.25.5"
Authenticated checkout of restrictedsubfolder OK (HTTP 207 result):
192.0.2.34 - auser - "PROPFIND /svn/myrepos HTTP/1.1" 207
665 "-" "SVN/1.4.0 (r21228) neon/0.25.5"
In fact, I even further analysed the raw HTTP
data. This is what happens for a restricted access root folder, if you
provide authentication:
* the subversion client access the HTTP page without authentication
* the server responds with a 401 result (Need authentication)
* the subversion client retries with authentication
* the server responds with a 207 result (OK)
* The repository metadata and a list of files is downloaded
Now, this is what happens for a publically accessible root folder, if
you provide authentications:
* the subversion client access the HTTP page without authentication
* the server responds with a 207 result (OK)
* The repository metadata and a partial list of files is downloaded
The list of downloaded file is PARTIAL, because it contains this data
(excerpt of the full XML transcript):
<S:absent-directory name="restrictedsubfolder"/>
<S:add-directory name="publicsubfolder"
bc-url="/svn/myrepos/!svn/bc/1/publicsubfolder">
<D:checked-in><D:href>
/svn/myrepos/!svn/ver/1/publicsubfolder
</D:href></D:checked-in>
So the restricted access subfolder is marked as "absent-directory". That
is true in this context, as the subversion client never provided
authentication. However, it means that the client will also never
attempt to download the data, despite that proper authentication was
given on the command line!
Versions:
subversion client: 1.4.0 (r21228), also tested with 1.4.2
subversion server: 1.4.0 (r21228), also tested with 1.3.0
neon (HTTP client): 0.25.5
Apache (HTTP server): 2.2.3
Regards,
Freek Dijkstra
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 11 15:34:58 2007