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: |
|
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)
#2
@
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
.
#3
@
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.
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
@
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
@
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
@
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
@
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 ); } );
According to http://php.net/manual/en/function.curl-setopt.php the
CURLOPT_PROXYAUTH
field accetps the same options asCURLOPT_HTTPAUTH
, however, only supports the subset ofCURLAUTH_BASIC
andCURLAUTH_NTLM
.As a result, passing
CURLAUTH_ANY
should work fine, it's the same as effectively passingCURLAUTH_BASIC | CURLAUTH_NTLM
.Can you explain a little more about the environment it's failing in, and if altering WordPress to pass
CURLAUTH_BASIC
orCURLAUTH_NTLM
fixes it for you?