On Mon, 23 Feb 2009 16:16:42 +0100, Daniel Stenberg wrote:
>
> Ugh, indeed you're right. Looking at this closer, the code checks for a
> *server context* unconditionally in output_auth_headers() instead of
> checking the proper proxy OR server context...

Indeed.
 
> What about this patch (against current CVS):

I applied it (by hand) to 7.19.3 and while I can't be positive it does
everything it's expected to, it does seem to eventually successfully
fetch the URL using the krb5 credentials. Super-yay!

Here's what seems strange. Even with a command line of:

$ http_proxy=http://brian@linux:3128/ ./curl -v --proxy-negotiate -o /dev/
null http://www.sun.com/

Where you can see I am obviously providing the username and telling curl
which proxy authentication method to use, I still see failed,
unauthenticated fetch before the GSS-Negotiate one. Here's the -v output
from curl (see notes below about the "bp" lines):

* About to connect() to proxy linux port 3128 (#0)
* Trying 10.75.22.3... connected
* Connected to linux (10.75.22.3) port 3128 (#0)
bp http.c:655
bp http.c:529 4 0x883cd48 (nil) (nil)
bp http.c:675
bp http.c:529 1 0x883cd28 (nil) (nil)
bp http.c:567
bp http.c:581
> GET http://www.sun.com/ HTTP/1.1
> User-Agent: curl/7.19.3 (i486-pc-linux-gnu) libcurl/7.19.3 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8
> Host: www.sun.com
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 407 Proxy Authentication Required
< Server: squid/3.0.STABLE10
< Mime-Version: 1.0
< Date: Tue, 24 Feb 2009 03:53:55 GMT
< Content-Type: text/html
< Content-Length: 1624
< Expires: Tue, 24 Feb 2009 03:53:55 GMT
< X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
< Proxy-Authenticate: Negotiate
< Proxy-Authenticate: Basic realm="Squid proxy-caching web server"
< X-Cache: MISS from linux
< X-Cache-Lookup: NONE from linux:3128
< Via: 1.0 linux (squid/3.0.STABLE10)
< Proxy-Connection: close
<
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 1624 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Closing connection #0
* Issue another request to this URL: 'http://www.sun.com/'
* About to connect() to proxy linux port 3128 (#0)
* Trying 10.75.22.3... connected
* Connected to linux (10.75.22.3) port 3128 (#0)
bp http.c:655
bp http.c:529 4 0x883cd48 0x8845160 (nil)
bp http.c:586
* Proxy auth using GSS-Negotiate with user 'brian'
bp http.c:675
bp http.c:529 1 0x883cd28 (nil) (nil)
bp http.c:567
bp http.c:581
> GET http://www.sun.com/ HTTP/1.0
> Proxy-Authorization: Negotiate Y...1jQ==
> User-Agent: curl/7.19.3 (i486-pc-linux-gnu) libcurl/7.19.3 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8
> Host: www.sun.com
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: Sun-Java-System-Web-Server/7.0
< Date: Tue, 24 Feb 2009 03:53:53 GMT
< P3p: policyref="http://www.sun.com/p3p/Sun_P3P_Policy.xml", CP="CAO DSP COR CUR ADMa DEVa TAIa PSAa PSDa CONi TELi OUR SAMi PUBi IND PHY ONL PUR COM NAV INT DEM CNT STA POL PRE GOV"
< Cache-Control: public
< X-powered-by: Servlet/2.4
< X-powered-by: JSP/2.0
< Set-Cookie: Starload=star-fep6; Path=/
< Set-Cookie: JSESSIONID=a66addb19dff154c5201aaf06d3c; Path=/
< Content-Type: text/html;charset=UTF-8
< Proxy-agent: Sun-Java-System-Web-Server/7.0
< Set-Cookie: JROUTE=s...k; Path=/
< Proxy-Authentication-Info: Negotiate AA==
< X-Cache: MISS from linux
< X-Cache-Lookup: MISS from linux:3128
< Via: 1.1 https-www, 1.0 linux (squid/3.0.STABLE10)
< Proxy-Connection: close
<
{ [data not shown]
1700 1624 1700 27205 0 0 43550 0 --:--:-- --:--:-- --:--:-- 99k* Closing connection #0

So, as you can see there are indeed two fetches. First one with no
authentication, which of course, fails, followed by a second with the
Negotiate authentication which succeeds.

About the "bp" lines. They are simply the result of:

fprintf(stderr, "bp %s:%d\n", __FILE__, __LINE__);

at various points in the code so I can see paths the code is following.

The one that has some extra information is the following in
output_auth_headers():

#ifdef HAVE_GSSAPI
fprintf(stderr, "bp %s:%d %d %p %p %p\n", __FILE__, __LINE__,
                authstatus->picked,
            negdata,
            negdata->context,
            negdata->state);
  if((authstatus->picked == CURLAUTH_GSSNEGOTIATE) &&
     negdata->context && !GSS_ERROR(negdata->status)) {
    auth="GSS-Negotiate";
    result = Curl_output_negotiate(conn, proxy);
    if(result)
      return result;
    authstatus->done = TRUE;
    negdata->state = GSS_AUTHSENT;
  }

So you can see, the first time through, output_auth_headers() is
called with authstatus->picked == CURLAUTH_GSSNEGOTIATE, but
negdata->context == NULL, so nothing really happens and the code
in the caller, http_output_auth() then falls through to line 662
and down through a second call to output_auth_headers from line
672. But this time authstatus->picked == CURLAUTH_BASIC but one
of the tests for 'auth="Basic"' in output_auth_headers() fails so
basically (no pun intended) control falls out of
output_auth_headers() and an unauthenticated request ends up
getting sent and refused (407) by the proxy server.

Then we seem to call http_output_auth() again and this time when
output_auth_headers() is called the first time, again with
authstatus->picked == CURLAUTH_GSSNEGOTIATE, negdata->context
has a valid value so Curl_output_negotiate() finally gets called.
But for whatever reason output_auth_headers gets called yet again
with no gss context and authstatus->picked == CURLAUTH_BASIC, but
again one of the assertions for 'auth="Basic"' fails and control
basically falls out of output_auth_headers() and the second request
gets sent, this time with the Negotiate header and the fetch is
successful.

So I guess the question is, why is an unauthenticated request sent
before every authenticated one, when curl is even being told to
use --proxy-negotiate?

Cheers,
b.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-02-24