Whoops! Sessions expired but still logged in error after payment (ePDQ - Barclay's)

[TwoWayRadio]

Hi all,

Hoping someone can help. Have spent hours searching for a solution and other people have had the same issue but no solution.

We're using Barclays ePDQ module and shared SSL. Checkout works great and payment is taken by Barclays. When the post back to edpq_result.php happens the page forwards to epdq_cpi_handler.php on the SECURE hosting which then immediately directs to (on the non secure webserver)...
index.php?main_page=time_out&zenid=h9hatjc75b4l2emk9p4j2284a4
This page produces the Whoops error page and does not create an order. When I use the test page to emulate a postback to generate the order using the oid={temporderno} the same error occurs, so definitely an issue with ZenCart.

We're using db session caching, epdq module and shared SSL.

Sessions in admin configured as follows...

Session Directory /home/linweb03/d/dksales.co.uk/user/htdocs/cache
Cookie Domain False
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true

Has anyone else experienced this or know of a fix? :)

[DrByte]

Does the same thing happen if you use one of the built-in payment modules instead of an addon? ie: check/moneyorder?

And, if you turn off SSL and do another test with your addon, do the same symptoms occur?

[TwoWayRadio]

Does the same thing happen if you use one of the built-in payment modules instead of an addon? ie: check/moneyorder?

And, if you turn off SSL and do another test with your addon, do the same symptoms occur?

Check/money order works fine. Have switched off SSL and it seems to work ok if I change the callback URL's.

[TwoWayRadio]

The epdq log table in ZC shows the transaction as a success (with the order no) so Barclays IS posting back, just Zen Cart is not creating the order. However when the customer clicks continue as a success but the redirect from cpi handler gives the whoops page and Zen Cart does not create the order. Does ZC require a session ID to be posted back? Im just wondering aside from the OID GET variable what else ZC needs to run the process_checkout?

[DrByte]

Everything it's doing requires that a valid session be present. If the callback system isn't passing the session back properly and the cookie isn't retaining the session properly, it's not going to work.

As you have acknowledged already, Fasthosts does odd unconventional things with their SSL setup, and frequently encounters these kinds of problems when attempting to complete transactions over SSL.

If check/moneyorder works fine then it's not a core Zen Cart issue with checkout.
And, if it works when switching off SSL to isolate causes, then it suggests the addon itself is largely okay, and generally seems to be pointing to an SSL issue ... which suggests a hosting problem.

[TwoWayRadio]

Everything it's doing requires that a valid session be present. If the callback system isn't passing the session back properly and the cookie isn't retaining the session properly, it's not going to work.

As you have acknowledged already, Fasthosts does odd unconventional things with their SSL setup, and frequently encounters these kinds of problems when attempting to complete transactions over SSL.

If check/moneyorder works fine then it's not a core Zen Cart issue with checkout.
And, if it works when switching off SSL to isolate causes, then it suggests the addon itself is largely okay, and generally seems to be pointing to an SSL issue ... which suggests a hosting problem.

When we installed the module we had to use the jump page fix to strip off the ZenID from the URL as Barclays ePDQ did not like dynamic URL's. On the jump page we strip off the zenid GET variable. Because we've stripped it is that whats causing the problem, or is the GET zenid variable not required?

[TwoWayRadio]

Dr Byte,
I've found the code that could be causing the error. Since the ePDQ log table is populated then I assume the postback from Barclays is working in epdqresult.php, so the next page is epdq_cpi_handler, which sends the data to checkout process.
In checkout process the following code mentions the timeout page...

// if the customer is not logged on, redirect them to the time out page
  if (!$_SESSION['customer_id']) {
    zen_redirect(zen_href_link(FILENAME_TIME_OUT));
  } else {
    // validate customer
    if (zen_get_customer_validate_session($_SESSION['customer_id']) == false) {
      $_SESSION['navigation']->set_snapshot(array('mode' => 'SSL', 'page' => FILENAME_CHECKOUT_SHIPPING));
      zen_redirect(zen_href_link(FILENAME_LOGIN, '', 'SSL'));
    }
  }

// confirm where link came from
if (!strstr($_SERVER['HTTP_REFERER'], FILENAME_CHECKOUT_CONFIRMATION)) {
  //    zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT,'','SSL'));
}

// BEGIN CC SLAM PREVENTION
if (!isset($_SESSION['payment_attempt'])) $_SESSION['payment_attempt'] = 0;
$_SESSION['payment_attempt']++;
if ($_SESSION['payment_attempt'] > 6) {
  zen_session_destroy();
  zen_redirect(zen_href_link(FILENAME_TIME_OUT));
}
// END CC SLAM PREVENTION

if (!isset($credit_covers)) $credit_covers = FALSE;

// load selected payment module
require(DIR_WS_CLASSES . 'payment.php');
$payment_modules = new payment($_SESSION['payment']);
// load the selected shipping module
require(DIR_WS_CLASSES . 'shipping.php');
$shipping_modules = new shipping($_SESSION['shipping']);

require(DIR_WS_CLASSES . 'order.php');
$order = new order;

Now given that when the customer gets the error page they are still logged in, along with their cart contents then I'm guessing it's not because they are logged out. Any ideas what else could be causing it?

[DrByte]

That code is checking to see whether the customer's id has been registered in the current session ... which is the primary indicator that the customer is actually logged in. If that fails, then it's redirecting to the timeout page. That code has been copied verbatim from Zen Cart core checkout code. And, while within regular Zen Cart checkout, Zen Cart will assume that if the person has reached this far into checkout and suddenly the customer id is no longer valid, that the customer must have been logged in at one time but the session must have expired or else the customer id wouldn't be missing ... hence the redirect to the timeout page. Your addon is assuming the same premise. Maybe that's an incorrect premise. But, whether it's valid to consider it a "timeout" or not, the fact remains: without a customer id, you're really NOT in that customer's session, so it's certainly appropriate to NOT continue doing any processing without getting back into the correct session again.

And, since the appropriate way to pass the session id back and forth is typically via the URL with a zenid, and you're stripping that off, you're really at a dead end.

If your gateway can't handle passing the required data back and forth, then it's really not ready for prime time.

[TwoWayRadio]

I've created a test page on both the secure and unsecure servers and the session value 'customerid' is always empty (even when logged in), yet ZC doesn't put it in the GET variables until you reach the 'My Account' or checkout pages. Barclays don't have a spare field for me to send the customer_id value and have it posted back, is there a workaround for this? If I create a session (e.g. 'tempcustid') myself using the value of the GET on the checkout page and then re-translate it back from a session value to a get value when I get the postback from Barclays will that work?

[DrByte]

No, that would be pointless. That's no different than passing the zenid as a GET parameter, which you said you can't do in the first place.