Session TimeOut during checkout

when i click on confirm order, it redirects me to a login page and says this

Whoops! Your session has expired.
If you were placing an order, please login and your shopping cart will be restored. You may then go back to the checkout and complete your final purchases.

If you had completed an order and wish to review it, please go to your My Account page to view your order.
Any insight onto why zencart is doing this, i am using authorize_sim module for my CC's

Thanks

What version of Zen Cart?
If you use a different payment module, does the same thing happen?
What addons do you have installed?
Is your SSL shared or dedicated? Or are you even using SSL? Does your SSL domain match your non-SSL domain?

Shoot, that happened to me once after having finally got the HSBC module to work today and I ignored it (thinking it was a one-off). Tonight it happens every time with different users, IE and FF. I haven't changed anything to do with php.ini and the timeout only seems to occur on the return from the HSBC gateway.
Anyone else still struggling to find an answer for this?

Ok guys & gals, another self-fix (and may not be logically the correct solution) but one others might like to know of.
It seems I unwittingly made a boo-boo whilst checking all configuration options this afternoon.
In the config/sessions the 'session directory' was set to something like "/var/.../cache" a path which could not be accessed on my virtual domain.
I set it to "/home/sites/mydomain/public_html/cart/cache" which is a valid directory and that's when the sessions started to be written to the directory but subsequently expired on completion of the payment transaction (with the "Whoops! Your session expired" message).
I have since blanked out the path/filename which in turn means that sessions are forced to be DB based (I'm pretty sure that is the case) and it works. Clearly with an invalid path previously the sessions must have also defaulted to being DB based.
So, though it works now I'd like to know how to get file based sessions to work correctly if anyone knows.

:blink:Seems like I put my mouth in gear before I did enough testing :(
Logging in with another user and trying a transaction resulted in the session error, so it is clearly much more subtle than I'd thought...

If it's only happening with your custom payment module, then perhaps you're doing something during its execution which is losing the session number or something similar.

File-based sessions require the /cache folder to be writable and your configure.php files set to use file-base caching.
For database-based, set the configure.php files to use database-based caching.

Don't forget that testing on a brand new clean uncustomized install can sometimes help prove whether non-working issues are a result of your customizations.

Thanks for those pointers. I have tried it with DB and file caching (validating the files get written to the cache) but still have the same problem.
The disappointing part is that I have made three successful transactions more 95% of the time I get the session timeout error.
Oh well tomorrow is another day...
Cheers.

Are you using SSL for your checkout, and if so, is your SSL domain different from your normal cart domain ??

I am using ssl and the ssl domain is different but synonymous, in other words https://web54.secure-secure.co.uk/MYDOMAIN.co.uk/cart/hsbc_return.php maps to
http://www.MYDOMAIN.co.uk/cart/hsbc_return.php

The fact that I have completed a small number of transactions suggests that the problem lies somewhere in the caching/session handling.

I have emptied the db_cache, sessions and whos_online tables, tried using file sessions, db sessions, force cookies etc to no avail.

I feel sure that someone else must have had this issue and resolved it successfully. Let's hope so as I am presently exhausted by it !

What happens if you disable SSL temporarily for testing? Do the problems go away?

I'm not sure that is an option with the HSBC gateway. If it is where is the config setting for that please?

ENABLE_SSL in your configure.php files

That's great thanks (sorry for missing the blindingly obvious but I have been avoiding any direct changes to the configure.php and assumed I could get to it from the admin CP). Your suggestion has been useful in an unexpected way.
I have a working system at present but it might be due in part to a combination of small changes.
Firstly I cleared the cache/zc_*.sql files. I had previously changed 'recreate sessions' to false (which it is currently set at) but that in itself did not cure the session timeout.
I was able to login and complete a transaction after clearing the cache.
Secondly I tried another user login, added an item to the cart and checked out. On return I got 'Your shopping cart is empty!' (it wasn't, it just looked like it on the page).
Thirdly I added another item to the basket having enabled SSL and the transaction completed successfully.
Finally I made a fresh transaction as the same (second) user and it completed successfully.

So in summary I am pretty unhappy about the relative stability right now, given that I don't understand the merits and potential side-effects of the session settings within zen cart (I understand sessions but not the apparent buggy behaviour I have been seeing within zc). It looks as if the suggestion you made has had an effect but not solely for the original problem -

define('ENABLE_SSL', 'true');

Thanks for your contribution. It is much appreciated. I'd like to get to the very bottom of the transaction instability. If I am able to put through a few dozen test transactions without further problems I'll cast my settings in stone.

You've been working on this using custom code for a module new to you in a framework that's new to you, and having problems.
Have you tried working with any of the built-in payment modules?

You couldn't be more right but I have been severely hampered by the HSBC end. I applied for a test store about seven weeks ago (it took five weeks). During the last two weeks I have made extremely slow progress with the HSBC secure payments outside of zc due to the fact that they rarely respond to emails and often state they'll call you back (and usually don't). The last two days I have been hounding them by phone and finally got somewhere thanks to the help of one tech guy.
Given that I had zc installed and configured all except for the gateway and that my client insisted on using HSBC I have been stuck between a rock and a hard place.
Ordinarilly I would take much longer to integrate (unknown) code but the launch party is on Saturday, so needs must. I do agree entirely with the sentiments in your comments.
As an aside, in another thread I have indicated that I have resolved a small number of issues with the 'foamcow' HSBC module and I wil be documenting that for all to share next week.
Using another (built-in) module may well have helped to determine if the issue was was the 3rd party module but it is that module (or equivalent) I have to make work.
As an update, I have a working system by the looks of it (I have performed many more transactions successfully).
Thanks :)

I am having the same problem.
My SSL domain is different from my normal domain (as shared SSL is). This is not a problem with my other site. The normal domain is https://www.goldduo.com and SSL goes to server.mochahost.com/..

The problem does not occur if SSL is not used.

Please help.
Thanks.

Well don't forget that in my case the ssl URL maps to the same domain as the cart host. That might be what I call a 'subtle irrelevance' but I draw your attention to it anyway.
The summary of my earlier postings amounts to the following in configure.php (what I think are the sensitive settings with respect to the session issue):

define('ENABLE_SSL', 'true');
define('STORE_SESSIONS', 'db');
define('SQL_CACHE_METHOD', 'file');
define('DIR_FS_SQL_CACHE', '/home/sites/MYDOMAIN/public_html/cart/cache');

and I have:

Session Directory /home/sites/MYDOMAIN/public_html/cart/cache
Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session False
IP to Host Conversion Status true

How do your settings differ?

Same problems here, everything was working fine until i rang up the hosting company and they changed the config files.

Working:
define('HTTP_SERVER', 'http://stargate.terrassl.net/stoves2be.com');
define('HTTPS_SERVER', 'https://stargate.terrassl.net/stoves2be.com');

they changed it.....

Not Working:
define('HTTP_SERVER', 'http://www.stoves2be.com');
define('HTTPS_SERVER', 'https://stargate.terrassl.net/stoves2be.com');

Hope that sheds anylight?

Thanks, Lee

oh and the hosting company informed me the problem was because i was using a custom template, so I changed back to the default template and i still get the error.

it seems that we are collecting a list of not-to-use hosting companies.

it will take me just 5 hours to rebuild the entire site and 72 hours to complete the change of DNS. the problem will almost certain be resolved in 72 hours..

I am running the exact same site on Hostgator without having the problem. Mochahost stinks! There is no comparison between mochahost and hostgator. the chat support people of mochahost are a bunch of ignorants that drink at work! There email support people will just tell you to purchase a private SSL after 30 hours of waiting! So if you ever consider - never touch mochahost! The other one to avoid is startlogic - their chat support will make you wait up to 1 hour!

I do not want to use Hostgator for my new site because I want some geographical distribution of my sites. I wonder what other hosts are good - at least that does not have this SSL time-out problem?