Steps to reproduce
RFC standard to be respected when having proxy is enabled and submitting a form with reCAPTCHA
Content-Type and Content-Length headers are sent to the proxy CONNECT request which violates RFC
Problem with plugin: CAPTCHA - reCAPTCHA
Joomla version: 3.9.12
Server environment: RedHat 7 with only official repository enabled.
Description: I'm using Joomla 3.9.12 with ENABLED PROXY and CAPTCHA - reCAPTCHA. The recaptcha is version 2.0 and used as default one.
When trying to register I'm getting the following error:
Recv failure: Connection reset by peer
500 Internal Server Error
CRITICAL error Uncaught \Throwable of type RuntimeException thrown. Stack trace:
#0 /libraries/src/Http/Http.php(213): Joomla\CMS\Http\Transport\CurlTransport->request('POST', Object(Joomla\CMS\Uri\Uri), Array, Array, NULL, NULL)
#1 /libraries/src/Captcha/Google/HttpBridgePostRequestMethod.php(66): Joomla\CMS\Http\Http->post('https://www.goo...', Array)
#2 /libraries/vendor/google/recaptcha/src/ReCaptcha/ReCaptcha.php(94): Joomla\CMS\Captcha\Google\HttpBridgePostRequestMethod->submit(Object(ReCaptcha\RequestParameters))
#3 /plugins/captcha/recaptcha/recaptcha.php(223): ReCaptcha\ReCaptcha->verify('', '')
#4 /plugins/captcha/recaptcha/recaptcha.php(178): PlgCaptchaRecaptcha->getResponse('', '', '', NULL)
#5 /libraries/joomla/event/event.php(70): PlgCaptchaRecaptcha->onCheckAnswer()
#6 /libraries/joomla/event/dispatcher.php(160): JEvent->update(Array)
...
This issue was introduced when upgraded Joomla to version 3.9.12. On Joomla version 3.8.12, the plugin works as expected.
Investigation done so far: When CAPTCHA - reCAPTCHA plugin makes the request to Google to check whether the recaptcha is valid, the request includes Content-Type and Content-Length headers.
The problem is that those headers are included in the CONNECT request sent to the proxy and that violates RFC (See https://tools.ietf.org/html/rfc7230#section-3.3.2).
Here's what the CONNECT request looks like on Joomla version 3.8.12:
10.134.56.168 TCP_TUNNEL/200 3605 CONNECT www.google.com:443 - HIER_DIRECT/172.217.18.196 - [10.134.56.168 TCP_TUNNEL/200 3605 CONNECT www.google.com:443 - HIER_DIRECT/172.217.18.196 - [
Proxy-Connection: Keep-Alive
Host: www.google.com:443
] []
and what it looks like on version 3.9.12:
248 10.134.56.168 TCP_TUNNEL/200 3180 CONNECT www.google.com:443 - HIER_DIRECT/216.58.207.36 - [248 10.134.56.168 TCP_TUNNEL/200 3180 CONNECT www.google.com:443 - HIER_DIRECT/216.58.207.36 - [
Proxy-Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 518
Host: www.google.com:443
]
Labels |
Added:
?
|
Since we are using curl and we only set the proxy to the curl library (https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Http/Transport/CurlTransport.php#L174-L185) which handles the proxy process transparent for joomla we can't do about this problem.
I would suggest to report this to php or curl maintainers.
But on older versions (3.8.12 for example) the plugin works as expected and RFC is respected. For me this sounds like an issue in newer versions of the plugin.
You are right in 3.9.0 we switched to the official google library while implementing invisible captcha.
But the new and the old version should both use the same transport...
I understand, however as I see the request to google service that verifies the recaptcha looks different. On the older version of the plugin (< 3.9.0) the data is sent as query parameters while on the newer version (>= 3.9.0) it is sent in the request body.
I see that this is the way the official google library works, but consider the following case:
I think that this is what the issue is all about.
I understand your issue but it still seams to be an curl issue.
Please try the following script
<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,"http://www.example.com/");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,
"postvar1=value1&postvar2=value2&postvar3=value3");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_PROXY, '<fill with proxy ip>');
curl_setopt($ch, CURLOPT_PROXYPORT, '<fill with proxy port>');
curl_setopt($ch, CURLOPT_HEADER, true);
$exec = curl_exec($ch);
var_dump(curl_error($ch));
var_dump(curl_getinfo($ch));
var_dump($exec);
curl_close ($ch);
?>
hmm @dginevaAxway please check whether an revert of this PR helps your case: https://github.com/joomla/joomla-cms/pull/24429/files
An what is the result of the script posed by @HLeithner above?
That won’t change anything, the web application has nothing to do with the HTTP package.
Oops .. I definitely need more sleep. :D
Labels |
Added:
Information Required
|
Closing due to lack of response. You can comment here and we can re-open the issue.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-12-30 01:20:50 |
Closed_By | ⇒ | Quy |
Since we are using curl and we only set the proxy to the curl library (https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Http/Transport/CurlTransport.php#L174-L185) which handles the proxy process transparent for joomla we can't do about this problem.
I would suggest to report this to php or curl maintainers.