Paypal module wrongfully state cURL is not enabled

[Zulgrib]

Describe the bug and add screenshots

cURL and php-cURL are installed and up to date, but the module wrongfully report they are not.
nginx is configured to only accept tls 1.2 and 1.3.
Official userguide do not state additional configuration is required for nginx.

Expected behavior

The module should show a green checkmark instead of a red cross for the cURL status.
If the problem is different, it should show a different error message. cURL is properly installed.

Steps to reproduce

1. Install Debian11
2. Install nginx
3. Install php-fpm and required php modules
4. Follow Prestashop's official documentation to configure nginx
5. Install this paypal module
6. Try to configure it and face errors

PrestaShop version(s) where the bug happened

1.7.8.8

PHP version(s) where the bug happened

7.4.33

[Zulgrib]

It looks like the message is wrong, cURL is okay but it fails the TLS test which is different, but blames cURL (and is still wrong, TLS 1.2 is enabled according to ssllabs.com)

The test function only returns meaningful error in case of HTTP 401 response.
https://github.com/202-ecommerce/paypal/blob/f732951a066b2134230b5412609c7f20182f1da4/classes/AdminPayPalController.php#L183
It should return any HTTP code different from 200

[Zulgrib]

nginx error logs returns

[error] 199902#199902: *25396 open() "/var/www/FQDN/module/paypal/tlscurltestserver" failed (2: No such file or directory), client: 51.77.200.207, server: FQDN, request: "GET /fr/module/paypal/tlscurltestserver HTTP/2.0", host: "FQDN"

And nginx is correct, the file is in "controllers/front", not in the root of the directory.

Again, there are no nginx documentation specific to this module or specific web server requirements.

There are no specific .htaccess file within the module that would redirect such calls properly, the only htaccess rule procided is for media files : Files ~ "(?i)^.*\.(jpg|jpeg|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|webp|woff|woff2|ttf|eot|otf|css|js)$".

[Zulgrib]

Manually accessing the curl tls url (where the file is, not module's root, within controllers/front) returns an error 500 because of line 30

PHP message: PHP Fatal error:  Uncaught Error: Class 'ModuleFrontController' not found in /var/www/FQDN/modules/paypal/controllers/front/tlscurltestserver.php:30
Stack trace:
#0 {main}
  thrown in /var/www/FQDN/modules/paypal/controllers/front/tlscurltestserver.php on line 30" while reading response header from upstream

[clotairer]

Hi,

1. We fix something about TLS version here Add TLS 1.3 checks (33017) #160 included in release 5.7.5 of Paypal module. What's the release of your module ?
2. About nginx configuration. More than 95% of this module are installed on Apache. htaccess had been added for security reason to prevent php direct calls event if no vulnerabilities are enabale. These rules are not mandatory and we consider they should be added in the "modules" directory of PrestaShop (becarefull some module don't use front controller). Please note I make a Pull Request here PrestaShop/PrestaShop@d973c3e (available on PS 8.1+) I'd like to unauthorize php call. So, we consider the paypal htaccess should be a generic rule of all modules. Feel free to port it on NGinx.
3. About /fr/module/paypal/tlscurltestserver > this is a native PrestaShop frontend controller. Your nginx rule should already match this rules. You can find a sample here

[Zulgrib]

Hello,

1. The version currently provided on addons.prestashop (declared as 5.7.5). The PR you link to only allows some checks to suceed for both TLS 1.2 and 1.3, it doesn't resolve cURL gets blamed while cURL isn't the issue like on first screenshot. (Real issue is the request generated and sent to cURL returns a 404, cURL did properly connect to the web server without issue since nginx logged the HTTP 404 error, my default nginx conf only allows TLS 1.2 and 1.3, meaning the protocol version is forcibly correct, it is wrong to assume the web server isn't TLS 1.2 or superior because you got a 404, the server sent you this 404 over HTTPS, you can verify from this 404 error the TLS version)
2. Not sure I understand, even if 95% of the module installs are on apache (how do you get these stats ? 26% of the web servers online are nginx, 10% are nginx fork openresty, only 20% are apache), unless you document only apache is supported, it should work with nginx when using Prestashop's official guideline to configure nginx, or nginx specific rules for the module should be provided.
3. I copy pasted from the page you linked, literally, just fixed the cert path, serv name and root path since path from exemple wouldn't work for obvious reasons. I will recheck the config to make sure.

[Zulgrib]

Found out I forgot this location block, but adding it did not resolve the issue. (And no reasons it would resolve it, you're not trying to access dot files)

        # .htaccess, .DS_Store, .htpasswd, etc.
        location ~ /\. {
                deny all;
        }

I see #58 was closed without resolution, which is cumulative to blame cURL for the error since having the store in maintenance mode makes your test file not reachable, while the real problem isn't cURL itself.

[clotairer]

@Zulgrib
The Paypal module work well on Nginx without any specific configuration on the module (I prefer this server too because performance is better but in PrestaShop context, I confirm Apache is prefered by PrestaShop merchant because it's easier to configure. But that's not the issue, we have several merchand with PrestaShop and Paypal module that work well).

If you have generic rules from PrestaShop configuration, you'll not have a 404 error and the TLS check will be OK.

[Zulgrib]

Okay, it doesn't resolve cURL is blamed while there are no cURL errors. (Even if someone force disable TLS 1.2 and 1.3, cURL isn't at fault and the text shouldn't blame cURL).

It also doesn't resolves #58 that blames cURL too, while cURL suceeded but got a non HTTP 200 response.

I'm insisting not to be annoying, but because lots of users on the Prestashop forum are pulling their hairs out trying to figure out what is wrong with cURL while cURL is not the fault.

[clotairer]

#58 issue is about maitnenance mode that return a 503 error not a 404 error.
Obviously the TLS check make a request on itself that's why if maintenance mode is enable, the module receive a 503 error.

In your case your the nginx configuration is not OK.

In my mind your URL is: /fr/module/paypal/tlscurltestserver
So I deduce that your have several languages.

I already configured a multishop (mono domain in sub directory) with nginx and in this case, I've specific rules to manager properly nGinx.

Perhap's you can check to enable only one language ?

[Zulgrib]

Yes I can, but the string in the files will still blame cURL in case of errors while the fault isn't on cURL.
I know i'm insisting here, it is due to the time Prestashop users will lose troubleshooting cURL while the problem is elsewhere.
Resolving my test case won't resolve cURL being wrongfully blamed.

edit : since help is wanted, I can at least modify the string for english and french for it to not blame wrongfully cURL.

[clotairer]

For your information, the check in the back-office is not mandatory to receive payments by Paypal.

Perhaps, the feature could change in case of 404 or 503 to hide this check and add a message like "TLS cannot be check now because your server response an error 404 (or 503) on the check request"

[Zulgrib]

It is minimal but would be better than blaming cURL.

Can't we verify TLS version using the home page?
PHP documentation state we can force a specific TLS version, setting it to 6 should ensure version below TLS 1.2 are refused. The documentation doesn't state it was added in "late" version, the module should remain compatible with PHP5.4.

It should be possible to catch the TLS mismatch error then ?

[montuy337513]

Hi @Zulgrib
Having the same problem I came across this issue.
Indeed, the translation does not help.
Then I finally solved this Curl detection problem by switching Apache to http2 protocol.
And under ngynx just add somewhere in the http2 config, a little Google will give the exact syntax.
If this can help