Suggestion to use CURL as the default request method.

[workguy66]

I suggest using CURL as the default request method if curl is available. It's waaaaaay more reliable and often enabled on server configs, I mean we all know that "fopen" and file_get_contents" is not a good idea to have enabled for urls.

I had the other two fail randomly for certain users while curl always works.

I still have no idea what made it fail, it's just too random to work with, I found other people complain about it for years (since v1) and still going.

Or just change your example to use CURL by default :)

$recaptcha = new \ReCaptcha\ReCaptcha($secret, new RequestMethod\CurlPost());

[rowan-m]

I can certainly update the documentation to make use of alternate methods more obvious.

I need to think more about changing the default behaviour though. I'm a little hesitant about the impact on existing installations if they update. I'm also not keen on depending on cURL extension or the added complexity in checking for it before falling back on the other method. That said, the security concerns are valid so I'll play around a bit and see what it looks like.

[workguy66]

@rowan-m I can totally understand your hesitation as many (VERY MANY) users will be affected.

Regarding the complexity I imagine something like

$this->requestMethod = (is_null($requestMethod)) ? new RequestMethod\Post() : $requestMethod;

becomes

if(isset($requestMethod)){
     $this->requestMethod = $requestMethod;
}elseif(function_exists('curl_version')){
     $this->requestMethod = new RequestMethod\CurlPost;
}else{
     $this->requestMethod = new RequestMethod\Post();
}

I know there are licence issues with sharing code (I read the contribution documentation) but I think it's too short of code to bother with those things (I may be wrong).

But I'll be happy with the documentation tweaks too :)

[workguy66]

It might be better to add a note about the security in the documentation and use curl as the default example, then future users will use the more reliable version while past users already got it working somehow.

Although maybe they also get errors randomly every now and then like I do with the default implementation. (Around 300 tests)

[LeonidasJP]

We regularly experience problems with the file_get_contents-call whilst using v1.2.1 of the PHP SDK. Mostly the errors are simply "Failed to open stream" errors, whilst file_get_contents and the SSL-stream are both enabled.

Is it an idea to implement an abstraction library like Guzzle under the hood? Since that checks itself whether Curl, file_get_contents and eventually other transport methods are enabled, and switches to whatever is available for it?

[semiaddict]

FYI, I was also experiencing issues with the default request method when using the Drupal module recaptcha_v3. Forcing the module to use the CurlPost method fixed the issue for me. However I wasn't able to figure out why the default request method with file_get_contents was always returning the following response:

{
  "success": false,
  "error-codes": [
    "missing-input-response",
    "missing-input-secret"
  ]
}

I tried debugging with XDebug, and all the parameters were correctly added in ReCaptcha\RequestMethod\Post::submit. Any ideas why this would haapen ?