Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#31232 closed defect (bug) (worksforme)

Invalid value for curl option CURLOPT_PROXYAUTH in wp-includes/class-http.php

Reported by: beiermichael's profile beier.michael Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: HTTP API Keywords:
Focuses: Cc:

Description

Hi,

in class-http.php CURLOPT_PROXYAUTH is set to CURLAUTH_ANY:

                        if ( $proxy->use_authentication() ) {
                                curl_setopt( $handle, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
                                curl_setopt( $handle, CURLOPT_PROXYUSERPWD, $proxy->authentication() );
                        }

According to http://php.net/manual/en/function.curl-setopt.php for proxy authentication, only CURLAUTH_BASIC and CURLAUTH_NTLM are currently supported.

Using a proxy requiring authentication is not possible due to this error.

Can you please fix this.

Best regards,
Michael

Change History (8)

#1 @dd32
10 years ago

  • Keywords reporter-feedback added

According to http://php.net/manual/en/function.curl-setopt.php the CURLOPT_PROXYAUTH field accetps the same options as CURLOPT_HTTPAUTH, however, only supports the subset of CURLAUTH_BASIC and CURLAUTH_NTLM.

CURLAUTH_ANY is an alias for CURLAUTH_BASIC | CURLAUTH_DIGEST | CURLAUTH_GSSNEGOTIATE | CURLAUTH_NTLM.

As a result, passing CURLAUTH_ANY should work fine, it's the same as effectively passing CURLAUTH_BASIC | CURLAUTH_NTLM.

Can you explain a little more about the environment it's failing in, and if altering WordPress to pass CURLAUTH_BASIC or CURLAUTH_NTLM fixes it for you?

Last edited 10 years ago by dd32 (previous) (diff)

#2 @beier.michael
10 years ago

My understanding of the documentation is, that setting CURLOPT_PROXYAUTH to CURLAUTH_ANY is not supported, but only CURLAUTH_BASIC and CURLAUTH_NTLM.

We're running Wordpress with PHP 5.5.17 (fpm, using apache 2.4 with mod_proxy_fcgi) on SLES11.

Using CURLAUTH_ANY the Proxy-Authorization Header was not sent in the request. After switching to CURLAUTH_BASIC it worked fine.

So I'd suggest to change it to CURLAUTH_BASIC | CURLAUTH_NTLM.

Last edited 10 years ago by beier.michael (previous) (diff)

#3 @dd32
10 years ago

After looking at the PHP source, and the cURL source, It looks like my original interpretation of the docs is correct, either should be able to be used, and since these are just plain bitmasks, they're designed to be interoperable.

https://github.com/bagder/curl/blob/0b1f37e77cc091456f32a8258a261b5a790ebf46/include/curl/curl.h#L624-L652

What kind of Proxy server are you connecting to, and what authorization method does it use? Basic or NTLM?
What version of cURL are you using with PHP 5.5.17? (get the cURL version from phpinfo(), not CLI) and is it a 32bit or 64bit build of PHP?

Looking at the constants in PHP, passing CURLAUTH_ANY or CURLAUTH_BASIC | CURLAUTH_NTLM definitely matches the same bitmasks, ideally we'd continue to use CURLAUTH_ANY to support future cURL proxy authentication methods (Although the Streams WP_HTTP Method only handles Basic..)

echo decbin( CONSTANT_NAME );
0001 CURLAUTH_BASIC  (1)
1000 CURLAUTH_NTLM   (8)
1001 CURLAUTH_BASIC | CURLAUTH_NTLM (9)
1111 CURLAUTH_BASIC | CURLAUTH_DIGEST | CURLAUTH_GSSNEGOTIATE | CURLAUTH_NTLM (15)

111111111111111111111111111111111111111111111111111111111110 1111  CURLAUTH_ANY (-17)
111111111111111111111111111111111111111111111111111111111110 1110  CURLAUTH_ANYSAFE (-18)

I've also just tested WP_HTTP with both a BASIC and a NTLM proxy using CURLAUTH_ANY, and both receive an appropriate Proxy-Authorization header.. So I'm really not sure why it's not working for you.
Tested With PHP 5.5.21 / cURL 7.19.7 / 64bit

#4 @beier.michael
10 years ago

The Proxy (Bluecoat) seems to be completely irrelevant, since Wordpress / libcurl does not put any Proxy-Authorization headers into the request. Worst case, it should behave like a "normal browser client" and retry after receiving a "407 Proxy-Authorization required" message from proxy - but it does not.

I use cURL 7.19.7 and php is 64bit too.

Currently I configured CURLAUTH_BASIC only, with this options it works fine.

#5 @dd32
10 years ago

Worst case, it should behave like a "normal browser client" and retry after receiving a "407 Proxy-Authorization required" message from proxy - but it does not.

This is exactly what I'm seeing, One request is made, hits a 407, it then makes a 2nd request with the proper Proxy-Authorization header according to the Proxy-Authenticate header.
If you force cURL to either use NTLM or Basic, then it appears that only one request is made with Proxy-Authenticate set to that, regardless of if the proxy is designed to handle it.

#6 @beier.michael
10 years ago

I debugged a little more and found out, that Wordpress indeed does send two requests for the same URL - but both without Proxy-Authorization header.

The proxy answers:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NEGOTIATE
Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="IWA_EnBW"

#7 @dd32
10 years ago

Still can't duplicate that behaviour even with NEGOTIATE present, so I'm not sure what's happening, It could be possible that you've run into a core cURL bug that needs to be reported to them. I'd try using the command line cURL and see if that succeeds.

I'll mull it over and think about what we can do, in the meantime, you can use this snippet in a plugin to force WP_HTTP's hand:

add_action( 'http_api_curl', function( $handle ) {
    curl_setopt( $handle, CURLOPT_PROXYAUTH, CURLAUTH_BASIC );
} );

#8 @dd32
10 years ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Marking as worksforme pending further reports and/or steps that can be duplicated with an open-source proxy.

Note: See TracTickets for help on using tickets.