kerberos authentication with neon 0.29.3

[Joe Orton]

On Thu, Mar 25, 2010 at 01:36:25AM +0300, Danil Shopyrin wrote:
> > How does this make a difference in the case reported?  After processing
> > the 2xx response does it generate a new SSPI token and send a new Auth
> > header in the next request?
> 
> No, the authentication process is finished after processing the 2xx
> response. But it's very important to process the final leg token
> because this allows clients to to check that server is "who he claims
> to be".

Right, sure.  So if I'm following this right, the behaviour being seen 
here is like this:

1. initial request gets an auth challenge:
C -> S : PROPFIND /foo 
S -> C : 401, WWW-Authenticate: Negotiate

2. req resent with SSPI token
C -> S : PROPFIND /foo, Authorization: Negotiate blob1
S -> C : 200, WWW-Authenticate: Negotiate blob2

3. subsequent request gets another auth challenge
C -> S : PROPFIND /bar [ -> no Authorization header] 
S -> C : 401, WWW-Authenticate: Negotiate

your patch is merely going to change step (2), right, to pass the 
"blob2" token back through SSPI?  How does this fix the problem that the 
subsquent request gets another 401 challenge?

Merely because the SSPI state machine isn't confused, and it's expecting 
a fresh challenge rather than a continuation of the old one?

Regards, Joe