Session TimeOut during checkout

Here is what solved my session time out problem.

http://www.zen-cart.com/forum/showthread.php?p=565262#post565262

That solution is kind of annoying - a separate certificate and separate IP for every store - or am I reading that incorrectly?

Did you try using multi-domain certificates? They are cheaper and then you would (theoretically) only need one IP.

Yes, this was the only solution they suggested for my case. Not too expensive.
Godaddy cert are on sale for about $14 each. IP I pay $1.5 a month and my host offered my a special package for hosting. So I am pretty happy despite the higher cost.

I think now my solution now is very clean. Separate accounts for each domain and SSL is cut for the used domain and nothing else.

multi-domain certificates work only if you don't have different domain names

Will not work:
store.mydomain.net
buy.anotherdomainname.com

Will work:
store.mydomain.net
buy.mydomain.net

At least this is how I understand it.

That is the way old certificates work. New ones (or at least my provider (domainsmadeeasy.com) allows for multiple domains per certificate, and changeable at any time, which is nice.

I just installed a new store for a different person, and I don't know if this is the case with the old store without my whole-site-ssl hack, but this one doesn't let me stay logged in via the admin at all. I'll have to play with it some more.

I am skeptical about this. Are you saying you own a Multiple Domain Certificate and you use it for:

https://www.domainnameone.com
and
https://www.domainnametwo.com
?

Please confirm, I was informed it only works for:

https://www.domainone.com
https://www.domainone.net
https://www.domainone.us
etc.

or subdomain.domainone.com

and then maybe the session problem will be an issue again?

Let me know your solution.

correct. I have a certificate for multiple domains, not just subdomains. I also have a certificate for wildcarded subdomains, but that is more common. I haven't seen the multiple domain certificates around very much.

By the way, I figured out my problem today. My first customer didn't care if I ran the whole site over SSL, but a new customer explicitly wanted the front page to not be under SSL.

So, looked around further, and wrote my own small session test script, and the same problem occurred there.

Sample script (from memory - I already erased it, but I can probably write it correctly)

I viewed this script from http://domain.com and watched it increment correctly. Then I viewed it at https://domain.com and saw that the count was reset to 0. Then I went back to http:// and saw that its session variable was also reset to 0!

I checked the session file (and moved it to a local directory using save_session_path in case I was going crazy) and saw that the session id never changed between http and https. Looking at the cookies, they were always the same too.

One thing that was funny was that the stuff in the session file was encrypted, which I first thought was maybe a feature of php5, but then realized that it was suhosin doing it (installed by default on Debian).

I looked through the configuration settings, and found that if I turned off the session encryption off (suhosin.session.encrypt) or I think even any of the settings (cryptraddr, cryptdocroot, or cryptua), but I think I had a caching issue when I was checking out the other settings, so I am not sure about that.

I couldn't find much documentation on them, so downloaded suhosin's source, and walked through that, and saw the docroot setting seemed like a possibility. I was also confused by why no one else is reporting this on google anywhere... Why does it only affect me??

The final solution....

A missing "/" in the docroot for the SSL site. Ugh. It doesn't matter to apache, but suhosin's encryption scheme uses the whole string, and so even though the cookie id was the same (and so apache/php used the same named session file) suhosin couldn't unencrypt the data using the other docroot, and so wiped the session, before continuing.

Everything is much happier (and sane) now.

Wow, glad you figured out your problem.
My host is using suhosin too. I wonder if my initial problem occurred because of the / thing. Don't know anything about suhosin myself but on a shared host, is this something I could check myself? Is there a file I could check for the / problem you mentioned? I would appreciate some simple instructions where to look.

Cpanel, linux apache hosting btw.

You need access to the suhosin configuration files. They will either be in your php.ini (if you have one, and in which case you might be able to change the settings to test) or in the system-wide versions. Mine is in /etc/php5/conf.d/suhosin.ini but that is the Debian way of doing things - I don't know if that is supported elsewhere.