kerberos authentication with neon 0.29.3

[Joe Orton]

Hi Danil, thanks a lot for taking the time to look into this!

On Wed, Mar 24, 2010 at 12:54:18AM +0300, Danil Shopyrin wrote:
> The behavior of neon in versions prior to 0.29.3 was the following:
> * The client ignores final leg token from the server. Kerberos
> authentication scheme is significantly violated.
> * As soon as the first Kerberos token is generated, the client
> re-sends it in each subsequent request. There can be two options:
>   - the token is transferred in the subsequent requests and is ignored
> by server.;
>   - re-authentication is performed for each subsequent request (it
> seems that mod_auth_kerb follows this way).
>   Both options seems to be incorrect.
> 
> We have prepared a simple patch that enables SSPI code to verify 2xx
> responses (attached). We have tested it with the VisualSVN Server and
> everything works fine for us. Review and any possible comments are
> welcome!

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?  (Otherwise, isn't the behaviour exactly the 
same; the *server* doesn't care know whether or not the client processed 
the 200 response token)

A minor nit in the patch:

> +static int verify_sspi(struct auth_request *req, auth_session *sess,
> +                       const char *hdr)
> +{
> +    int ntlm = ne_strncasecmp(hdr, "NTLM ", 5) == 0;

isn't it redundant to check that, since the verify_sspi() callback will 
only be used for Negotiate exchanges?

Regards, Joe