You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johannes Michler <or...@gmail.com> on 2014/02/22 18:16:11 UTC

Unable to access our SVN server using SVN 1.8 client

Hi,

we're serving a svn repository using Debian 7 and mod_dav_svn.so in apache:
Apache/2.2.22 (Debian) DAV/2 SVN/1.6.17 PHP/5.4.4-14+deb7u7

We want to have all members of a certain ldap-group to have full access.
Furthermore, some users from the ldap-directory not in that group shall
have access to certain paths. So our setup is:

<Location /svn>
  DAV svn
  SVNPath /data1/svn
     AuthName "SVN Authentifizierung"
     AuthType Basic
     AuthBasicProvider ldap
     AuthLDAPUrl
ldap://LDAP-SERVER:389/CN=Users,DC=intern,DC=nixda,DC=de?sAMAccountName
     AuthLDAPBindDN "binduser"
     AuthLDAPBindPassword password
     AuthLDAPGroupAttributeIsDN on
     Require ldap-group CN=Mitarbeiter,CN=Users,DC=intern,DC=nixda,DC=de
     AuthzSVNAuthoritative off
     AuthzSVNAccessFile /etc/apache2/dav_svn.authz
</Location>

Furthermore my dav_svn.authz file is:

[svn:/PROJEKTE/KUNDE1/trunk/R12]
user1 = rw

This is working great in browsers and with SVN 1.7.14 Clients. However with
1.8.X Clients I'm getting Access denied errors on Checkout. Here's my
server logfile with Collabnet 1.7.14 client: (For svn co
https://myserver//svn/PROJEKTE/KUNDE1/trunk/R12/Forms)

192.168.202.108 - - [22/Feb/2014:17:54:29 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
/svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 524 "-" "SVN/1.7.14 neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 647 "-"
"SVN/1.7.14 neon/0.29.6"
192.168.202.108 - - [22/Feb/2014:17:54:31 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
/svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 neon/0.29.6"
192.168.202.108 - user1 [22/Feb/2014:17:54:32 +0100] "REPORT
/svn/!svn/vcc/default HTTP/1.1" 200 686 "-" "SVN/1.7.14 neon/0.29.6"


However with 1.8.8 (e.g. from tortoisesvn, but it doesn't depend on that):

192.168.202.108 - - [22/Feb/2014:17:55:42 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 818 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
/svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 503 "-"
"SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - - [22/Feb/2014:17:55:44 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 818 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12 HTTP/1.1" 207 860 "-"
"SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"
192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8
(x64-microsoft-windows) serf/1.3.4"



I think it is a bug of the 1.8 client to ask for the parents of the Folder
to checkout. It doesn't seem to be a issue of serf vs. neon, since this is
what happens when setting http-library=serf with SVN 1.7:

192.168.202.108 - - [22/Feb/2014:18:13:44 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 798 "-" "SVN/1.7.14
serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 882 "-" "SVN/1.7.14
serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
/svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
/svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 503 "-"
"SVN/1.7.14 serf/1.2.1"
192.168.202.108 - - [22/Feb/2014:18:13:45 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 798 "-" "SVN/1.7.14
serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "OPTIONS
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 882 "-" "SVN/1.7.14
serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND
/svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND
/svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND
/svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 serf/1.2.1"
192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "REPORT
/svn/!svn/vcc/default HTTP/1.1" 200 635 "-" "SVN/1.7.14 serf/1.2.1"



Any ideas? Can I do something on the serverside? Or will there be a
fix/workaround for this in the client?


Regards,
Johannes

Re: Unable to access our SVN server using SVN 1.8 client

Posted by Ben Reser <be...@reser.org>.
On 2/25/14, 3:37 PM, Ben Reser wrote:
> Both mod_authz_default and mod_authz_forbid are registering in the
> APR_HOOK_LAST group.  So their order is not determinate.  If you want to avoid
> mod_authz_forbid activating for any other traffic (with or without
> mod_authz_default) loaded you should add the following directive inside your
> server level of your httpd.conf (i.e. outside a Location/Directory block):
> AuthzForbidAuthoritative On

The above should be "AuthzForbidAuthoritative Off".  Sorry about the typo.

Re: Unable to access our SVN server using SVN 1.8 client

Posted by Ben Reser <be...@reser.org>.
On 2/25/14, 12:52 PM, Ben Reser wrote:
> 2) Write a custom authz hook that always returns HTTP_FORBIDDEN that hooks
> after the ldap module.  Configure your custom module to be turned on for your
> location.  Then set 'AuthzLDAPAuthoritative off', meaning that the ldap module
> will DECLINE and the final module should handle this.
> 
> I'm off to lunch but when I get back I can probably write a quick authz module
> that does the second bit for you.

First of all I was able to duplicate this with a SVN 1.6.x server, 1.8.x client
and the following setup (without needing LDAP since group file module has the
same behavior):

httpd.conf:
[[[
<Location /svn>
  DAV svn
  SVNPath ${HOME}/iprops
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile ${HOME}/iprops/conf/users
  AuthGroupFile ${HOME}/iprops/conf/groups
  Require group constant
  AuthzSVNAuthoritative off
  AuthzSVNAccessFile ${HOME}/iprops/conf/authz
</Location>
]]]

users (password is rayjandom for both):
[[[
jrandom:xCGl35kV9oWCY
jconstant:xCGl35kV9oWCY
]]]

groups:
[[[
constant: jconstant
]]]

authz:
[[[
[/random]
jrandom = rw
]]]

I was able to make it work by adding the attached module.  It's a slightly
hacked version of mod_authz_default, which comes with httpd 2.2.x (and also
returns a 401).  The only differences are I changed the name of the symbols and
configuration settings so that it doesn't conflict with mod_authz_default.

The following should install it (note that on Debian use apxs2 instead of apxs):
apxs -cia mod_authz_forbid.c

Now add the following extra options to the Location block for SVN:
[[[
  AuthzDefaultAuthoritative Off
  AuthzGroupFileAuthoritative Off
]]]

And now it works with a 1.8 client.  The first directive is only needed if
mod_authz_default is built in or loaded as a module.  The second line is the
correct option to disable authoritative in the group module.  In your case
you'd want to use "AuthzLDAPAuthoritative off".

The mod_authz_default module is intended as a fallback in case of there are
Requires lines but no authz hooks is configured as authoritative, which default
behavior in httpd would be to allow that access.  So it is desirable to leave
this module enabled but simply enable it for where you're using the
mod_authz_forbid module I've attached.

Both mod_authz_default and mod_authz_forbid are registering in the
APR_HOOK_LAST group.  So their order is not determinate.  If you want to avoid
mod_authz_forbid activating for any other traffic (with or without
mod_authz_default) loaded you should add the following directive inside your
server level of your httpd.conf (i.e. outside a Location/Directory block):
AuthzForbidAuthoritative On

Fwd: AW: Unable to access our SVN server using SVN 1.8 client

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
I accidentally responded only to Ben:


On 2/25/14, 7:37 PM, Nico Kadel-Garcia wrote:
> And, sometimes, it just gets more reliable to use svn+ssh and avoid
> the entire Apache infrastructure complexity. There are so *many*
> variants of authentication, and filesystem and multi-platform feature
> interaction that avoiding the potentially complex web configuration
> aspects is sometimes very helpful. It's sometimes so very easy to get
> *wrong*, especially if you're starting to use sophisticated features,
> that getting it right becomes quite complex.
>
> That's why I've long been a big proponent of HTTP or HTTPS for
> anonymous access, svn+ssh for write access. and in some cases
> reliability. I don't know if that's feasible in this case....

Re: AW: Unable to access our SVN server using SVN 1.8 client

Posted by Ben Reser <be...@reser.org>.
On 2/25/14, 1:25 PM, Markus Schaber wrote:
> I tend to think it might be a sensible behavior to not prompt for 
> Authentication on the client side during specifically this kind of 
> upwards tree walk when the client successfully authenticated for the
> "main" request, and later fails with the same credentials for a parent
> directory - it could catch this situation, and just treat it like a
> "forbidden" internally.
> 
> However, I'm not sure whether this is easy to implement given the
> asynchronous, parallel architecture of serf...

If only it were so simple.  HTTP is stateless.

Just because the credentials worked for some of the requests doesn't mean they
will continue working for all requests.  Authentication credentials can change.
 If you just think about passwords that seems absurd but you can't just think
about passwords in this case.

Digest authentication has the ability to expire nonces.  The server gets to
decide if the client should be prompted to provide authentication again or not
with the stale=TRUE flag.  Kerberos has tickets that can expire.

Even with basic auth a user can change their password in the middle of an
operation.  If you think that's silly consider a enterprise system with a
checkout that takes a long time to run and a user decides to change their
password in the middle (probably a bad idea but we really shouldn't fail).

That said this whole thing does raise the issue that a 1.8.x client talking to
a 1.7.x or older server that's configured with mixed anonymous/authenticated
access is going to prompt users for a password when doing the PROPFINDs for
inherited properties unless the anonymous user has access all the way up to the
root.  When the user happens to have credentials you can consider this
beneficial.  When the user is a fully anonymous user then this turns into a
hassle that means anonymous users have to know to enter a bogus password to
trigger the code to stop the inherited properties walk.  Granted setups like
this are already problematic in other ways, so this isn't entirely new.  I'd
imagine that's why we haven't already had someone complaining about this.

In my opinion Subversion needs the 401/403 distinction to really work properly.
 There are too many intertwined protocols/implementation details to avoid that
now.  Add one more detail to why using a stateless protocol is annoying.

AW: Unable to access our SVN server using SVN 1.8 client

Posted by Markus Schaber <m....@codesys.com>.
Hi, Ben,

Von: Ben Reser [mailto:ben@reser.org]
> 
> On 2/25/14, 12:03 PM, Johannes Michler wrote:
> > Well but by looking into my logfiles I see that my server is indeed
> > sending HTTP-401. Is this the problem?
> 
> I don't think there's really anything that a 1.8 client can or should do
> different here.  The server is saying "give me authn credentials" and the
> client is trying to ask for them.  The same problem exists for a 1.7 client,
> it's just that we don't walk up into trees that you're not expecting so
> you're not seeing this sort of loop (and currently mod_dav_svn returns errors
> rather than 401's for secondary paths).

I tend to think it might be a sensible behavior to not prompt for 
Authentication on the client side during specifically this kind of 
upwards tree walk when the client successfully authenticated for the
"main" request, and later fails with the same credentials for a parent
directory - it could catch this situation, and just treat it like a
"forbidden" internally.

However, I'm not sure whether this is easy to implement given the
asynchronous, parallel architecture of serf...


Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915


Re: Unable to access our SVN server using SVN 1.8 client

Posted by Ben Reser <be...@reser.org>.
On 2/25/14, 12:03 PM, Johannes Michler wrote:
> Well but by looking into my logfiles I see that my server is indeed sending
> HTTP-401. Is this the problem?

I don't think there's really anything that a 1.8 client can or should do
different here.  The server is saying "give me authn credentials" and the
client is trying to ask for them.  The same problem exists for a 1.7 client,
it's just that we don't walk up into trees that you're not expecting so you're
not seeing this sort of loop (and currently mod_dav_svn returns errors rather
than 401's for secondary paths).

Looking at the source for mod_authnz_ldap it appears to return a 401 if the
group check fails.

You've got two basic options here.

1) Patch mod_authnz_ldap so that it returns HTTP_FORBIDDEN.  Note that this may
cause problems with other configurations that aren't using LDAP this way.

2) Write a custom authz hook that always returns HTTP_FORBIDDEN that hooks
after the ldap module.  Configure your custom module to be turned on for your
location.  Then set 'AuthzLDAPAuthoritative off', meaning that the ldap module
will DECLINE and the final module should handle this.

I'm off to lunch but when I get back I can probably write a quick authz module
that does the second bit for you.



Re: Unable to access our SVN server using SVN 1.8 client

Posted by Johannes Michler <or...@gmail.com>.
Well but by looking into my logfiles I see that my server is indeed sending
HTTP-401. Is this the problem?

Regards,
Johannes


2014-02-25 20:51 GMT+01:00 Ben Reser <be...@reser.org>:

> On 2/25/14, 11:44 AM, Johannes Michler wrote:
> > well I'm using Apache 2.2:
> > apache2 -v
> > Server version: Apache/2.2.22 (Debian)
> > Server built:   Jan 31 2014 18:55:37
> >
> > Is there a workaround for 2.2 as well?
>
> Yeah just realized that looking at your original mail.  2.2 shouldn't have
> that
> behavior.
>
>

Re: Unable to access our SVN server using SVN 1.8 client

Posted by Ben Reser <be...@reser.org>.
On 2/25/14, 11:44 AM, Johannes Michler wrote:
> well I'm using Apache 2.2:
> apache2 -v
> Server version: Apache/2.2.22 (Debian)
> Server built:   Jan 31 2014 18:55:37
> 
> Is there a workaround for 2.2 as well?

Yeah just realized that looking at your original mail.  2.2 shouldn't have that
behavior.


Re: Unable to access our SVN server using SVN 1.8 client

Posted by Johannes Michler <or...@gmail.com>.
Hi Ben,

well I'm using Apache 2.2:
apache2 -v
Server version: Apache/2.2.22 (Debian)
Server built:   Jan 31 2014 18:55:37

Is there a workaround for 2.2 as well?

Regards,
Johannes



2014-02-25 20:36 GMT+01:00 Ben Reser <be...@reser.org>:

> On 2/25/14, 11:04 AM, Johannes Michler wrote:
> > well the client is asking over and over again and finally gives up:
> > C:\Users\jmichler\Desktop\test>svn co
> https://SERVER/svn/PROJEKTE/KUNDE1/trunk/R12/
> > Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
> > Password for 'user1': ********
> > Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
> > Username: user1
> > Password for 'user1': ********
> > Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
> > Username: user1
> > Password for 'user1': ********
> > svn: E215004: No more credentials or we tried too many times.
> > Authentication failed
>
> If you're running httpd 2.4.x you probably want this directive in your
> configuration:
> AuthzSendForbiddenOnFailure on
>
>
> http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authzsendforbiddenonfailure
>
>

Re: Unable to access our SVN server using SVN 1.8 client

Posted by Ben Reser <be...@reser.org>.
On 2/25/14, 11:04 AM, Johannes Michler wrote:
> well the client is asking over and over again and finally gives up:
> C:\Users\jmichler\Desktop\test>svn co https://SERVER/svn/PROJEKTE/KUNDE1/trunk/R12/
> Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
> Password for 'user1': ********
> Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
> Username: user1
> Password for 'user1': ********
> Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
> Username: user1
> Password for 'user1': ********
> svn: E215004: No more credentials or we tried too many times.
> Authentication failed

If you're running httpd 2.4.x you probably want this directive in your
configuration:
AuthzSendForbiddenOnFailure on

http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authzsendforbiddenonfailure


Re: Unable to access our SVN server using SVN 1.8 client

Posted by Johannes Michler <or...@gmail.com>.
Hi Bert,

well the client is asking over and over again and finally gives up:
C:\Users\jmichler\Desktop\test>svn co
https://SERVER/svn/PROJEKTE/KUNDE1/trunk/R12/
Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
Password for 'user1': ********
Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
Username: user1
Password for 'user1': ********
Authentication realm: <https://SERVER:443> PROMATIS Authentifizierung
Username: user1
Password for 'user1': ********
svn: E215004: No more credentials or we tried too many times.
Authentication failed

Of cause my credentials are fine,

Regards,

Johannes


2014-02-25 9:24 GMT+01:00 Bert Huijben <be...@qqmail.nl>:

>  What error do you see in TortoiseSVN or other 1.8 clients?
>
> Subversion 1.8 will look at parent directories to find inherited
> properties,  but it will just ignore properties on directories which it
> can't read.
>
>       Bert
>
> Sent from Windows Mail
>
> *From:* Johannes Michler <or...@gmail.com>
> *Sent:* Saturday, February 22, 2014 6:16 PM
> *To:* users@subversion.apache.org
>
> Hi,
>
> we're serving a svn repository using Debian 7 and mod_dav_svn.so in apache:
> Apache/2.2.22 (Debian) DAV/2 SVN/1.6.17 PHP/5.4.4-14+deb7u7
>
> We want to have all members of a certain ldap-group to have full access.
> Furthermore, some users from the ldap-directory not in that group shall
> have access to certain paths. So our setup is:
>
> <Location /svn>
>   DAV svn
>   SVNPath /data1/svn
>      AuthName "SVN Authentifizierung"
>      AuthType Basic
>      AuthBasicProvider ldap
>      AuthLDAPUrl
> ldap://LDAP-SERVER:389/CN=Users,DC=intern,DC=nixda,DC=de?sAMAccountName
>      AuthLDAPBindDN "binduser"
>      AuthLDAPBindPassword password
>      AuthLDAPGroupAttributeIsDN on
>      Require ldap-group CN=Mitarbeiter,CN=Users,DC=intern,DC=nixda,DC=de
>      AuthzSVNAuthoritative off
>      AuthzSVNAccessFile /etc/apache2/dav_svn.authz
> </Location>
>
> Furthermore my dav_svn.authz file is:
>
> [svn:/PROJEKTE/KUNDE1/trunk/R12]
> user1 = rw
>
> This is working great in browsers and with SVN 1.7.14 Clients. However
> with 1.8.X Clients I'm getting Access denied errors on Checkout. Here's my
> server logfile with Collabnet 1.7.14 client: (For svn co
> https://myserver//svn/PROJEKTE/KUNDE1/trunk/R12/Forms)
>
> 192.168.202.108 - - [22/Feb/2014:17:54:29 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
> /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 524 "-" "SVN/1.7.14 neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 647 "-"
> "SVN/1.7.14 neon/0.29.6"
> 192.168.202.108 - - [22/Feb/2014:17:54:31 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
> neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND
> /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 neon/0.29.6"
> 192.168.202.108 - user1 [22/Feb/2014:17:54:32 +0100] "REPORT
> /svn/!svn/vcc/default HTTP/1.1" 200 686 "-" "SVN/1.7.14 neon/0.29.6"
>
>
> However with 1.8.8 (e.g. from tortoisesvn, but it doesn't depend on that):
>
> 192.168.202.108 - - [22/Feb/2014:17:55:42 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 818 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
> /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 503 "-"
> "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - - [22/Feb/2014:17:55:44 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 818 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12 HTTP/1.1" 207 860 "-"
> "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
> 192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8
> (x64-microsoft-windows) serf/1.3.4"
>
>
>
> I think it is a bug of the 1.8 client to ask for the parents of the Folder
> to checkout. It doesn't seem to be a issue of serf vs. neon, since this is
> what happens when setting http-library=serf with SVN 1.7:
>
> 192.168.202.108 - - [22/Feb/2014:18:13:44 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 798 "-" "SVN/1.7.14
> serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 882 "-" "SVN/1.7.14
> serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
> serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
> /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND
> /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 503 "-"
> "SVN/1.7.14 serf/1.2.1"
> 192.168.202.108 - - [22/Feb/2014:18:13:45 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 798 "-" "SVN/1.7.14
> serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "OPTIONS
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 882 "-" "SVN/1.7.14
> serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND
> /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14
> serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND
> /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND
> /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 serf/1.2.1"
> 192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "REPORT
> /svn/!svn/vcc/default HTTP/1.1" 200 635 "-" "SVN/1.7.14 serf/1.2.1"
>
>
>
> Any ideas? Can I do something on the serverside? Or will there be a
> fix/workaround for this in the client?
>
>
> Regards,
> Johannes
>

Re: Unable to access our SVN server using SVN 1.8 client

Posted by Bert Huijben <be...@qqmail.nl>.
What error do you see in TortoiseSVN or other 1.8 clients?


Subversion 1.8 will look at parent directories to find inherited properties,  but it will just ignore properties on directories which it can't read.


      Bert






Sent from Windows Mail





From: Johannes Michler
Sent: ‎Saturday‎, ‎February‎ ‎22‎, ‎2014 ‎6‎:‎16‎ ‎PM
To: users@subversion.apache.org





Hi,



we're serving a svn repository using Debian 7 and mod_dav_svn.so in apache:

Apache/2.2.22 (Debian) DAV/2 SVN/1.6.17 PHP/5.4.4-14+deb7u7





We want to have all members of a certain ldap-group to have full access. Furthermore, some users from the ldap-directory not in that group shall have access to certain paths. So our setup is:





<Location /svn>

  DAV svn

  SVNPath /data1/svn

     AuthName "SVN Authentifizierung"

     AuthType Basic

     AuthBasicProvider ldap

     AuthLDAPUrl ldap://LDAP-SERVER:389/CN=Users,DC=intern,DC=nixda,DC=de?sAMAccountName

     AuthLDAPBindDN "binduser"

     AuthLDAPBindPassword password

     AuthLDAPGroupAttributeIsDN on

     Require ldap-group CN=Mitarbeiter,CN=Users,DC=intern,DC=nixda,DC=de

     AuthzSVNAuthoritative off

     AuthzSVNAccessFile /etc/apache2/dav_svn.authz

</Location>




Furthermore my dav_svn.authz file is:





[svn:/PROJEKTE/KUNDE1/trunk/R12]

user1 = rw




This is working great in browsers and with SVN 1.7.14 Clients. However with 1.8.X Clients I'm getting Access denied errors on Checkout. Here's my server logfile with Collabnet 1.7.14 client: (For svn co https://myserver//svn/PROJEKTE/KUNDE1/trunk/R12/Forms)





192.168.202.108 - - [22/Feb/2014:17:54:29 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:29 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 524 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:30 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 647 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - - [22/Feb/2014:17:54:31 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:31 +0100] "PROPFIND /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 neon/0.29.6"

192.168.202.108 - user1 [22/Feb/2014:17:54:32 +0100] "REPORT /svn/!svn/vcc/default HTTP/1.1" 200 686 "-" "SVN/1.7.14 neon/0.29.6"







However with 1.8.8 (e.g. from tortoisesvn, but it doesn't depend on that):





192.168.202.108 - - [22/Feb/2014:17:55:42 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 818 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:43 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 503 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - - [22/Feb/2014:17:55:44 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 679 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 865 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 818 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12 HTTP/1.1" 207 860 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"

192.168.202.108 - user1 [22/Feb/2014:17:55:44 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk HTTP/1.1" 401 678 "-" "SVN/1.8.8 (x64-microsoft-windows) serf/1.3.4"










I think it is a bug of the 1.8 client to ask for the parents of the Folder to checkout. It doesn't seem to be a issue of serf vs. neon, since this is what happens when setting http-library=serf with SVN 1.7:





192.168.202.108 - - [22/Feb/2014:18:13:44 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 798 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 882 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:44 +0100] "PROPFIND /svn/!svn/bc/29062/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 503 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - - [22/Feb/2014:18:13:45 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 401 798 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "OPTIONS /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 200 882 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND /svn/PROJEKTE/KUNDE1/trunk/R12/Forms HTTP/1.1" 207 639 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND /svn/!svn/vcc/default HTTP/1.1" 207 504 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "PROPFIND /svn/!svn/bln/29062 HTTP/1.1" 207 518 "-" "SVN/1.7.14 serf/1.2.1"

192.168.202.108 - user1 [22/Feb/2014:18:13:45 +0100] "REPORT /svn/!svn/vcc/default HTTP/1.1" 200 635 "-" "SVN/1.7.14 serf/1.2.1"










Any ideas? Can I do something on the serverside? Or will there be a fix/workaround for this in the client?





Regards,

Johannes