Sudden Epath Gateway Problem

[robertluer]

In case it helps, I have observed the following cookie behaviour in Chrome in the following 2 situations:

$samesite = 'lax'; (Symptom - all sessions in edge, chrome and firefox time out when returning to site from epath)
Zenid cookie shows:
Send for - Same-site connections only
Expires - When browsing session ends
Session Storage - no cookie selected

$samesite = 'none'; (Symptom - all sessions in chrome time out, firefox and edge still work)
No Zenid cookie showing in chrome
Session Storage - no cookie selected

FYI Charlie and Alexander from Epath are also following this thread and have expressed interest in working with developers to try and sort this out.

[lat9]

What's the process used by ePath when returning to the site? Are there any iframes involved?

[e-Path]

What's the process used by ePath when returning to the site? Are there any iframes involved?

No, no iframes.

We return the customer back to the site via POST with number of values attached.

We have been scratching our heads over this and would like to do what we can to assist the customer.

Firstly, we did another two test orders and dummy payments on this customer's site using Chrome (the browser he mentions).

The first order went through without issues.

However, when we attempted a second order we got the "Whoops! Your session has expired." error message.

Could it be that this is only effecting people coming back a second time?

I know the customer, with the help of some kind individuals in this forum, has been working on trying to stop Zen Cart session time out's but perhaps the issue is the opposite. Maybe this should be about ensuring session time out's happens after a set period of time so that if the customer comes back again Zen Cart and therefore browser's will see it as a brand new session.

As you can probably tell we are a little handicapped with this one because none of us here are Zen Cart software programmers.

But we have a lot of flexibility to be able to try anything our side on the customer's gateway because with e-Path every single gateway customer of ours has their own individual system.

Further, we notice the return URL being sent to e-Path (captured from one of our test orders) is ...

https://[domain-removed]/shop/index....1b91ea7e90ffe1

Can we ask, is the "zenid" which is present in the string, the only value Zen Cart needs returned? If so then perhaps we'll just make it a straight link back to the customer's site rather than a POST. At the moment we are returning customers via POST which has a number of values being returned with it. Would this help?

Thank you

Peter

[lat9]

No, no iframes.

We return the customer back to the site via POST with number of values attached.

We have been scratching our heads over this and would like to do what we can to assist the customer.

Firstly, we did another two test orders and dummy payments on this customer's site using Chrome (the browser he mentions).

The first order went through without issues.

However, when we attempted a second order we got the "Whoops! Your session has expired." error message.

Could it be that this is only effecting people coming back a second time?

I know the customer, with the help of some kind individuals in this forum, has been working on trying to stop Zen Cart session time out's but perhaps the issue is the opposite. Maybe this should be about ensuring session time out's happens after a set period of time so that if the customer comes back again Zen Cart and therefore browser's will see it as a brand new session.

As you can probably tell we are a little handicapped with this one because none of us here are Zen Cart software programmers.

But we have a lot of flexibility to be able to try anything our side on the customer's gateway because with e-Path every single gateway customer of ours has their own individual system.

Further, we notice the return URL being sent to e-Path (captured from one of our test orders) is ...

https://[domain-removed]/shop/index.php?main_page=checkout_process&zenid=e1e474506f5a8725021b91ea7e90ffe1

Can we ask, is the "zenid" which is present in the string, the only value Zen Cart needs returned? If so then perhaps we'll just make it a straight link back to the customer's site rather than a POST. At the moment we are returning customers via POST which has a number of values being returned with it. Would this help?

Thank you

Peter

Thanks for the details, Peter. That zenid parameter indicates that there's something amiss in the customer's session setup, referred to as a "sticky zenid". That parameter should be present only on the initial "hit" of the store.

What could be done to mitigate the problem on the customer's site is to return (along with your POSTed values) that $_GET variable zenid.

[e-Path]

Thanks for the details, Peter. That zenid parameter indicates that there's something amiss in the customer's session setup, referred to as a "sticky zenid". That parameter should be present only on the initial "hit" of the store.

What could be done to mitigate the problem on the customer's site is to return (along with your POSTed values) that $_GET variable zenid.

Nice of you lat9 to be helping to trouble shoot things for this Zen Cart user.

$_GET doesn't work for us.

The addition of the zenid in the URL could be the problem. I have checked with my team and they tell me, that as far as they are aware, Zen Cart sends the return URL as ...

https://domain-removed/shop/index.ph...eckout_process

Therefore, is there a way to not have the zenid part added to this URL? Could the return URL be hard coded on the Zen Cart software side?

What if I had my guys simply hard code the return URL in to his gateway without the zenid part? The various other values will still be returned as usual as we understand your software needs them to recognize the customer back. This is not the ideal scenario because it means if he changes his Zen Cart install location or changes his domain, then obviously the customer will not be return to his shop. Thoughts?

Peter

[lat9]

Nice of you lat9 to be helping to trouble shoot things for this Zen Cart user.

$_GET doesn't work for us.

The addition of the zenid in the URL could be the problem. I have checked with my team and they tell me, that as far as they are aware, Zen Cart sends the return URL as ...

https://domain-removed/shop/index.ph...eckout_process

Therefore, is there a way to not have the zenid part added to this URL? Could the return URL be hard coded on the Zen Cart software side?

What if I had my guys simply hard code the return URL in to his gateway without the zenid part? The various other values will still be returned as usual as we understand your software needs them to recognize the customer back. This is not the ideal scenario because it means if he changes his Zen Cart install location or changes his domain, then obviously the customer will not be return to his shop. Thoughts?

Peter

When Zen Cart generates the return-link and it includes the zenid= parameter, it's an indication that there's something amiss with the site's session-configuration.

Is it not possible for ePath to return to the full URL supplied ... including that parameter?

That zenid= is Zen Cart's way of keeping the session information for the active customer when the session cookie's storage has issues.

[robertluer]

Would like to try and sort any session configuration issues. Was reading another thread about sticky zenid (https://www.zen-cart.com/showthread....s-all-the-time). Was wondering whether Dr Bytes post #8 might help resolve the sticky zenid in chrome? Here's a sanitized version of my includes/configures.php file:

<?php
/**
* @package Configuration Settings
* @copyright Copyright 2003-2018 Zen Cart Development Team
* @copyright Portions Copyright 2003 osCommerce
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* File Built by Zen Cart Installer on Thu Sep 19 2019 11:49:14
*/

/*************** NOTE: This file is VERY similar to, but DIFFERENT from the "admin" version of configure.php. ***********/
/*************** The 2 files should be kept separate and not used to overwrite each other. ***********/

/**
* Enter the domain for your store
* HTTP_SERVER is your Main webserver: eg-http://www.yourdomain.com
* HTTPS_SERVER is your Secure/SSL webserver: eg-https://www.yourdomain.com
*/
define('HTTP_SERVER', 'http://cxxxxxxxxxxxxp.com');
define('HTTPS_SERVER', 'https://cxxxxxxxxxxxxp.com');

/**
* If you want to tell Zen Cart to use your HTTPS URL on sensitive pages like login and checkout, set this to 'true'. Otherwise 'false'. (Keep the quotes)
*/
define('ENABLE_SSL', 'true');

/**
* These DIR_WS_xxxx values refer to the name of any subdirectory in which your store is located.
* These values get added to the HTTP_CATALOG_SERVER and HTTPS_CATALOG_SERVER values to form the complete URLs to your storefront.
* They should always start and end with a slash ... ie: '/' or '/foldername/'
*/
define('DIR_WS_CATALOG', '/sxxp/');
define('DIR_WS_HTTPS_CATALOG', '/sxxp/');

/**
* This is the complete physical path to your store's files. eg: /var/www/vhost/accountname/public_html/store/
* Should have a closing / on it.
*/
define('DIR_FS_CATALOG', '/home/xxxxxxx/public_html/sxxp/');

/**
* The following settings define your database connection.
* These must be the SAME as you're using in your admin copy of configure.php
*/
define('DB_TYPE', 'mysql'); // always 'mysql'
define('DB_PREFIX', 'xxx_'); // prefix for database table names -- preferred to be left empty
define('DB_CHARSET', 'utf8'); // 'utf8mb4' or older 'utf8' / 'latin1' are most common
define('DB_SERVER', 'localhost'); // address of your db server
define('DB_SERVER_USERNAME', 'xxxxxxxx_xxxxxxx');
define('DB_SERVER_PASSWORD', 'xxxxxxxxxxx');
define('DB_DATABASE', 'xxxxxxxx_xxxxxxx');

/**
* This is an advanced setting to determine whether you want to cache SQL queries.
* Options are 'none' (which is the default) and 'file' and 'database'.
*/
define('SQL_CACHE_METHOD', 'none');

/**
* Reserved for future use
*/
define('SESSION_STORAGE', 'reserved for future use');

/**
* Advanced use only:
* The following are OPTIONAL, and should NOT be set unless you intend to change their normal use. Most sites will leave these untouched.
* To use them, uncomment AND add a proper defined value to them.
*/
// define('DIR_FS_SQL_CACHE' ...
// define('DIR_FS_DOWNLOAD' ...
// define('DIR_FS_LOGS' ...

// End Of File
********************************

Should I try changing my includes/configure file to define('HTTP_SERVER', 'https://www.mydomain.com'); and define('ENABLE_SSL', 'true'); // change to false - and if so, do I need to make changes to the admin_configure.php file too?

Sanitized version of admin/configures.php file:

<?php
/**
* @package Configuration Settings
* @copyright Copyright 2003-2018 Zen Cart Development Team
* @copyright Portions Copyright 2003 osCommerce
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* File Built by Zen Cart Installer on Thu Sep 19 2019 11:49:14
*/


/*************** NOTE: This file is VERY similar to, but DIFFERENT from the "store" version of configure.php. ***********/
/*************** The 2 files should be kept separate and not used to overwrite each other. ***********/

/**
* Enter the domain for your Admin URL. If you have SSL, enter the correct https address in the HTTP_SERVER setting, instead of just an http address.
*/
define('HTTP_SERVER', 'https://cxxxxxxxxxxxxp.com');
/**
* Note about HTTPS_SERVER:
* There is no longer an HTTPS_SERVER setting for the Admin. Instead, put your SSL URL in the HTTP_SERVER setting above.
*/

/**
* Note about DIR_WS_ADMIN
* The DIR_WS_ADMIN value is now auto-detected.
* In the rare case where it cannot be detected properly, you can add your own DIR_WS_ADMIN definition below.
*/

/**
* Enter the domain for your storefront URL.
* Enter a separate SSL URL in HTTPS_CATALOG_SERVER if your store supports SSL.
*/
define('HTTP_CATALOG_SERVER', 'http://cxxxxxxxxxxxxp.com');
define('HTTPS_CATALOG_SERVER', 'https://cxxxxxxxxxxxxp.com');

/**
* Do you use SSL for your customers login/checkout on the storefront? If so, enter 'true'. Else 'false'.
*/
define('ENABLE_SSL_CATALOG', 'true');

/**
* These DIR_WS_xxxx values refer to the name of any subdirectory in which your store is located.
* These values get added to the HTTP_CATALOG_SERVER and HTTPS_CATALOG_SERVER values to form the complete URLs to your storefront.
* They should always start and end with a slash ... ie: '/' or '/foldername/'
*/
define('DIR_WS_CATALOG', '/sxxp/');
define('DIR_WS_HTTPS_CATALOG', '/sxxp/');

/**
* This is the complete physical path to your store's files. eg: /var/www/vhost/accountname/public_html/store/
* Should have a closing / on it.
*/
define('DIR_FS_CATALOG', '/home/xxxxxx/public_html/sxxp/');

/**
* NOTE about DIR_FS_ADMIN
* The value for DIR_FS_ADMIN is now auto-detected.
* In the very rare case where there is a need to override the autodetection, simply add your own definition for it below.
*/

/**
* The following settings define your database connection.
* These must be the SAME as you're using in your non-admin copy of configure.php
*/
define('DB_TYPE', 'mysql'); // always 'mysql'
define('DB_PREFIX', 'xxx_'); // prefix for database table names -- preferred to be left empty
define('DB_CHARSET', 'utf8'); // 'utf8mb4' or older 'utf8' / 'latin1' are most common
define('DB_SERVER', 'localhost'); // address of your db server
define('DB_SERVER_USERNAME', 'xxxxxxxx_xxxxxxx');
define('DB_SERVER_PASSWORD', 'xxxxxxxxxxxxx');
define('DB_DATABASE', 'xxxxxx_xxxxxxxx');

/**
* This is an advanced setting to determine whether you want to cache SQL queries.
* Options are 'none' (which is the default) and 'file' and 'database'.
*/
define('SQL_CACHE_METHOD', 'none');

/**
* Reserved for future use
*/
define('SESSION_STORAGE', 'reserved for future use');

/**
* Advanced use only:
* The following are OPTIONAL, and should NOT be set unless you intend to change their normal use. Most sites will leave these untouched.
* To use them, uncomment AND add a proper defined value to them.
*/
// define('DIR_FS_SQL_CACHE' ...
// define('DIR_FS_DOWNLOAD' ...
// define('DIR_FS_LOGS' ...

// End Of File

******************
And below is a sanitized screenshot from my admin server info:

[lat9]

@robertluer, make sure that the permissions are set properly (normally 775, but some hosts require 777) for the site's /cache directory. If that directory's not writable, that could be the cause of your "sticky zenid".

[robertluer]

Thanks Cindy for all your help, much appreciated. Changed permissions on the cache file to 777. Used second variant of that code in the includes/init_includes file (see https://www.zen-cart.com/showthread.php?227136) and installed that new extra_datafiles file and initial testing looks to have solved the issue in Chrome while also now working in other browsers too. Epath now reverting successfully back to checkout_success page even after one minute.

[lat9]

Thanks Cindy for all your help, much appreciated. Changed permissions on the cache file to 777. Used second variant of that code in the includes/init_includes file (see https://www.zen-cart.com/showthread.php?227136) and installed that new extra_datafiles file and initial testing looks to have solved the issue in Chrome while also now working in other browsers too. Epath now reverting successfully back to checkout_success page even after one minute.

Woo-hoo! Thanks for the feedback on the cache permissions and the fact that the ePath payment method requires the samesite=none;secure form of (er) samesite cookie.