Session TimeOut during checkout

[slikie]

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

[DrByte]

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?

[sdclee]

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?

[sdclee]

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.

[sdclee]

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...

[DrByte]

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.

[sdclee]

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.

[wilt]

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

[sdclee]

I am using ssl and the ssl domain is different but synonymous, in other words https://web54.secure-secure.co.uk/MY...sbc_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 !

[DrByte]

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