Serf not handling negotiate authentication correctly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install collabnet 1.7.0-dev r1136035
2. Perform any svn operation against a Subversion server (mod_auth_kerb) that 
offers both negotiate and basic authentication.
3. Watch as Serf endlessly responds to the 401 authenticate with a new 
unauthenticated request.  User must ctrl-c the application.

What is the expected output? What do you see instead?
Expect serf to fall back to basic authentication if not supported but offered 
by the server or fail with an error message if no authentication methods are 
supported.

What version of the product are you using? On what operating system?
serf 0.8.0
svn 1.7.0-dev
apache 2.2.17
mod_auth_kerb 4.2

Please provide any additional information below.

Discussed on the Subversion developers list:
http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/129419

Original issue reported on code.google.com by kmra...@gmail.com on 24 Jun 2011 at 2:17

[GoogleCodeExporter]

Entered wrong mod_auth_kerb version.  Should be:
mod_auth_kerb 5.4

Running client on Windows XP, tested self built Subversion servers on Solaris 
10 and Linux RHEL 6.

Original comment by kmra...@gmail.com on 24 Jun 2011 at 2:26

[GoogleCodeExporter]

The question here is: why doesn't the negotiate authentication not succeed?

If it is because the user is on a different domain, or any other error where 
the SERVER decides to stop the kerberos authentication , then this is the same 
as issue 77.

If it is because the user doesn't have a kerberos tgt (kinit not run), so the 
kerberos authentication on the CLIENT fails, then I see that serf does not 
hang, but ends with authn failed error. This is not good either, as it should 
fallback to Basic. This is fixed in r1507.

If it is because GSSAPI/SSPI are not available, then serf falls back to Basic 
automatically, so that works ok.

Original comment by lieven.govaerts@gmail.com on 25 Jun 2011 at 9:47

[GoogleCodeExporter]

s/doesn't ...not/doesn't/

Original comment by lieven.govaerts@gmail.com on 25 Jun 2011 at 9:48

[GoogleCodeExporter]

Couple of additional things:

1) Does serf use a different default for http-auth-types?  It seems to try 
negotiate when nothing is specified.  Neon seems to not use it by default.  I 
needed to specify http-auth-types without negotiate to get serf to use basic 
only.
2) The client does have/get a valid certificate when neon is used.  Only thing 
changed is to switch http-library=serf to make it fail.
3) I was testing with a secondary domain that has a bi-directional trust.  I'll 
try and simplify test test to narrow down the behavior to make sure it is not a 
setup issue on my end.  I am now seeing an initial 200 OK repsponse from the 
server, but then the next request has no authentication and is getting a 401.  
This could very well be closely related to issue #77.

Original comment by kmra...@gmail.com on 25 Jun 2011 at 1:57

[GoogleCodeExporter]

This one should be implicitly fixed with issue 89 when I see:

3. Watch as Serf endlessly responds to the 401 authenticate with a new 
unauthenticated request.  User must ctrl-c the application.

Any comments Lieven?

Original comment by 1983-01...@gmx.net on 7 Nov 2012 at 12:48

[GoogleCodeExporter]

Yeah, that sounds exactly like the problem I was seeing when I created this 
issue.

Original comment by kmra...@gmail.com on 7 Nov 2012 at 3:47

[GoogleCodeExporter]

Yup, that sounds like per-request authentication. Serf 1.2.0 (unreleased) 
should solve this issue for you.

Original comment by lieven.govaerts@gmail.com on 3 Jan 2013 at 7:47

• Changed state: Fixed