payer auth verifier causes session timeout error

[02-Sep-2020 13:45:50 Europe/London] Request URI: /index.php?main_page=payer_auth_verifier, IP address:
#1 session_id() called at [/home/site/public_html/includes/modules/pages/payer_auth_verifier/header_php.php:55]
#2 require(/home/site/public_html/includes/modules/pages/payer_auth_verifier/header_php.php) called at [/home/site/public_html/index.php:36]
--> PHP Warning: session_id(): Cannot change session id when session is active in /home/site/public_html/includes/modules/pages/payer_auth_verifier/header_php.php on line 55.

1.5.6c PHP Version: 7.3.21

I've verified the bug myself and also verified that the bug doesn't happen 100% of the time.

When clicking the final stage to confirm, the verifier page fails with a session timeout error.

When attempting payment via paypaldp I get the error.

// Get the MD back and set it as the session id

  if (isset($_REQUEST["MD"]) && $_REQUEST["MD"] != null && strlen($_REQUEST["MD"]) != 0) {

    session_id($_REQUEST["MD"]);

  }

when watching in "whos online" you can see that the customer session dies and they become a guest on that page.

Can I also mention that the firing of this warning does not result in a failure.

I can see that the warning is being given for successful sales, but i can also confirm that there is an issue somewhere.

After clicking the final confirm button, the stage where the card check takes place, during this check, a session timeout error is shown, not sure of cause.

I have the similar issue. Time out after payment, customer session becomes a guest session.
https://www.zen-cart.com/showthread.php?227136-Bambora-Payform-Session-expired-after-some-payments-instead-of-checkout_success

Your problem is different, this problem causes the transaction to fail before completion.

Would the store still be able to operate if PayPal Express were instead used? Or rather what problems would the store have if operated using PayPal Express?

I use both, i use paypaldp for on site card payments, 40% of transactions are done using card on the site.

So far all logged issues have been with users using chrome, from version 83 to 85.

Also, I don't believe the issue was happening when I used the paypal payment code from before 1.5.5

I had been using the paypal code from version 1.5.4 due to a problem with payflow UK and the newer paypal code.

See this thread

I have only had this problem since no longer using the 1.5.4 code.

I managed to use the 1.5.6c paypal code by switching PayPal Express Checkout PayPal mode from Payflow-UK to PayPal. This has got round the problems in the thread above, but has now introduced a problem with the onsite payments.

I believe both issues are linked.

Please DrByte, look into this.

I've implemented the changes to my 1.5.6c site as mentioned by lat9 on this thread

Waiting to see if any improvement to the situation is seen.

DigitalShadow:

So far all logged issues have been with users using chrome, from version 83 to 85.

Also, I don't believe the issue was happening when I used the paypal payment code from before 1.5.5

I had been using the paypal code from version 1.5.4 due to a problem with payflow UK and the newer paypal code.

I have only had this problem since no longer using the 1.5.4 code.

I managed to use the 1.5.6c paypal code by switching PayPal Express Checkout PayPal mode from Payflow-UK to PayPal. This has got round the problems in the thread above, but has now introduced a problem with the onsite payments.

I believe both issues are linked.

Please DrByte, look into this.
Thanks for providing a few more hints... Can you tell if the warnings are from users with supported 3d secure cards or non 3d secure cards? It is a UK thing right now. Ether way, session_id() is not correct in php grater then 7.0.. I'm not sure when this changed and going backwards is not desired.. PHP7.3 started reporting such failures, with 7.0 and 7.1 not reporting which is way you would not see the warring with them. I'm not a Paypal user so figuring out what the code is doing and the correct way to change the hand shake would be better by a Paypal user with a sandbox.. Just wanted to point out that a change in PHP versions is why you can now see it. Poor WiFi network, mobile networks could be leading to failed carts by resetting sessions, so pin pointing issues is difficult for someone not having problems.

Searching the net for info about 3d secure, Paysafe developer gave me the most helpful info, Paypal developer hints at the possibility of turning off 3d secure within your paypal account... if so, that may be the route to go until better answers can be created. Hope that helps a bit...

Building on @davewest's observations, I've seen where the 3D-Secure processing can 'come back' to a site's checkout_process multiple times and result in a time_out due to what's perceived as checkout-slamming.

While there's also a notification/observer means of changing that slamming threshold, you could try making a template override of /includes/modules/checkout_process.php and changing that threshold to something a bit larger (like 6).

// BEGIN CC SLAM PREVENTION
$slamming_threshold = [B]3[/B];
if (!isset($_SESSION['payment_attempt'])) $_SESSION['payment_attempt'] = 0;

I've not noticed any more timeout problems since making the changes I mentioned above.

However, not all customers reported the issue during checkout, so some issues may still be happening.

I never had this issue when using the 1.5.4 paypal code and php 5.x

Seems to be a php 7+ / 1.5.5+ code issue. However, It is beyond me to know what is causing the problem. However, I wonder if it is only 7.3+

One thing I have noticed, which may help those better at understanding these issues.

My sites are forced https by setting the config file http and https values to both https urls.

If you are on a product page and reload the page as a http link instead of https, then attempt to add the item to your cart, it won't work on php 7.3, you get a session expired error.

If i switch the site back to php 5.xx or 7.2 it works fine, the product is added to cart correctly from a http session and converted to a https session.

However, switching back to php 7.2 stops login working, presume the code lat9 put would require a check for php versions below 7.3 so the old session code would be used instead

would this work

if (PHP_VERSION_ID < 70300) 

obviously building the rest of the if statement

I can confirm, that trying to add an item to the cart from http page does not correctly switch to https session, it fails with time out.

This issue is only on php 7.3, changing to a php version below 7.3 fixes the problem.

I wonder if the payment timeout issues above would be solved by running the site on php 7.2 instead of 7.3

I think this should be investigated at zen 1.5.6c should be 7.3 compatible.

Other functions work correctly moving from http to https, but adding to cart fails.

I wonder if my CORS policy is the problem?

The add to cart button is a https link, when clicking that link from a http page, the site does not transition correctly from a http session to https resulting in the timeout.

Seems to only happen on php 7.3+ doesn't matter which init_session code i use (original or lat9), this bug persists.

I take that statement back, I've recreated this bug from php 7.1+

php 5.6 handles the switch from http page to https cart, 7.1+ does not

DigitalShadow:

I take that statement back, I've recreated this bug from php 7.1+

php 5.6 handles the switch from http page to https cart, 7.1+ does not
If your site's running https-all-the-time, you should have an .htaccess file that forces the site to https to prevent these type of issues.

I have done that now, why would php 5.6 cope with that problem but not php 7+

DigitalShadow:

I have done that now, why would php 5.6 cope with that problem but not php 7+

Looking through the developer docs for 3d secure cards, they're a little veg on what's needed to bring into ZC as reply's other then the returning MD which is required.. May be something like save, regenerate, restore.. Look at your Paypal account to see what you can disable...

Again, the docs suggest that the warnings are due to 3d secure and the code not properly handling changing the session id to the returning MD which is a session ID from results of the processing of 3d secure.. Cards that are 3d secure members well fail, cards that are not members well pass without issues until the session ID is correctly handled.

PHP 5.6 wasn't really coping with it, it just wasn't telling you anything.. PHP7.4 is even more fun...