kerberos authentication with neon 0.29.3
Danil Shopyrin
danil at visualsvn.com
Thu Mar 18 14:45:08 EDT 2010
Hi All!
> Thanks for that. Yes, I presume it's Danil's change to stop sending the
> SSPI token which causes the issue here.
>
> Danil: the issue you saw with resending the SSPI token, was that only
> with an NTLM exchange, or a Negotiate exchange? It doesn't really make
> sense to be resending the SSPI token in either case, but clearly it's
> making a difference somehow.
We're looking into this issue.
> I notice that the SSPI code does not
> process the server's response token in the 2xx response as the GSSAPI
> code; maybe this is the issue but I can't fathom how.
Thanks for notice.
> We could do something like this which partially reverts the behaviour:
>
> Index: src/ne_auth.c
> ===================================================================
> --- src/ne_auth.c (revision 1792)
> +++ src/ne_auth.c (working copy)
> @@ -1468,8 +1468,8 @@
> #endif
>
> #ifdef HAVE_SSPI
> - /* whatever happens: forget the SSPI token cached thus far */
> - if (sess->sspi_token) {
> + /* For an NTLM exchange: forget the SSPI token cached thus far */
> + if (strcmp(sess->protocol->name, "NTLM") == 0 && sess->sspi_token) {
> ne_free(sess->sspi_token);
> sess->sspi_token = NULL;
> }
This change can avoid the problem. But I think it will be better to
process 2xx response just like the GSSAPI does.
I hope we will be able to provide an appropriate patch in the
beginning of the next week.
--
With best regards,
Danil Shopyrin
VisualSVN Team
More information about the neon
mailing list