Hi David,

> Gesendet: Donnerstag, 17. Juli 2014 um 11:41 Uhr
> Von: "David Woodhouse" <dwmw2_at_infradead.org>
> An: "Kamil Dudka" <kdudka_at_redhat.com>
> Cc: curl-library_at_cool.haxx.se, "Daniel Stenberg" <daniel_at_haxx.se>
> Betreff: Re: [PATCH] http: avoid auth failure on a duplicated header
>
> On Fri, 2014-05-09 at 13:46 +0200, Kamil Dudka wrote:
> > On Friday 09 May 2014 13:25:21 Daniel Stenberg wrote:
> > > On Fri, 9 May 2014, Kamil Dudka wrote:
> > > > ... 'WWW-Authenticate: Negotiate' received from server
> > >
> > > Seems reasonable to me!
> >
> > Thanks for review! I have pushed the patch:
> >
> > https://github.com/bagder/curl/commit/ec5fde24
>
> Hrm, I think I just broke this again. In retrospect, it wasn't the right
> fix. We really do need to process WWW-Authenticate: Negotiate even when
> we're in the GSS_AUTHSENT state.
>
> However, if we're in the GSS_AUTHRECV state, that means we have already
> *received* a 'WWW-Authenticate: Negotiate' header on *this* time round
> the loop.... doesn't it?
>
> So the code I just submitted is *almost* doing the right thing by
> processing it only when the state us GSS_AUTHNONE or GSS_AUTHSENT.
>
> It's just that it shouldn't necessarily be setting
> data->state.authproblem when it sees the duplicate header; it should be
> ignoring it. So do we just remove the 'else' clause at line 793 of
> http.c?
>
> There's also another, deeper problem with both this and the original
> patch referenced above... it assumes that the first of the duplicate
> headers is actually the one we want.
>
> In this case there was an empty 'WWW-Authenticate: Negotiate\r\n' and
> also another one with a token, and the one with the token came *first*
> so that was fine.
>
> But in the case where we get an empty header and *then* one with a
> token, surely it'll still be the one with the token that we want to
> process? So perhaps we actually want some kind of pre-processing to
> happen rather than taking the first one we see?
>
> Could we just *store* the token at this point, then do the work of
> producing the result later in Curl_output_negotiate()? Or is that much
> too hard because we also need to know at input time whether we're going
> to *try* each auth method...?

Given a server sends a single response header:

After my commit would have been merged, I wanted to rework that stuff anyway.
As I have already layed out before, the enum 'state' is not well-designed. It needs to be tied to context state.

The issue is that your server does not behave the way intended. That requires a custom fix in curl.
The other issue with curl is that it performs preemptive auth which is a bug because the RFC say MAY. That requires an option --preemptive.
Especially, not all acceptors are capable of processing preemptive auth.

Michael
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-07-17