Whoops! Your session has expired.

[RoboPhung]

So I'm revisiting this issue as my website is picking up more activity and I'm getting an increasing number of customers complaining that they get session timed out during the final phase of the checkout process which also begins to throw them into a log-in loop (whereby they attempt to log in after the session timeout message repeatedly and it does not appear to log them into the website).

I've sat down and really tried to drill down the source of the issue, so I checked out the cc slamming code in checkout_process.php and I see the function which you are referring to, Dr. Byte, but I no longer believe that this is the reason behind most of my customer session timeouts. The code only sets the payment_attempt variable to zero and iterates it by 1 once a credit card number is actually inputted in an accepted format (i.e. 16 total digits for a Visa number, etc) and the payment info was actually forwarded to the financial institution for processing. For example, I use PayPal website payments pro, and a customer correctly inputs their cc number but puts the wrong cvc code. Then payment_attempt iterates by 1, and after 3 more unsuccessful tries, the session is forced timed out and, most importantly to note, the shopping cart contents are destroyed and I get an email via PayPal notifying me of each unsuccessful payment attempt that was made. So other types of incorrect CC entries (such as forgetting to type a digit so the customer only typed 15 or doubletyped a digit for a total of 17) don't count as payment attempts that trigger the credit card slamming.

I've tested and seen the iteration of payment_attempts by inserting this code to display the number of checkout attempts in the tpl_checkout_stacked.php file:

echo "Checkout Attempt Number {$_SESSION['payment_attempt']}

So on the checkout confirmation page, I can see the live count going up when credit card numbers are actually submitted to PayPal for processing attempt that fails, and the counter stay stagnant when Zen-Cart detects that the credit card number is not even a valid format to begin with.

I know you know all this already, Dr. Byte, but the reason why I'm pointing this all out to you is because, for all of my customers who have so far notified me of their difficulties in checking out because they get session timed out when they hit the button to "confirm order", the important things I've noticed is that I did not receive PayPal emails for any of those specific customers indicating that they had attempted to pay unsuccessfully a few times beforehand, and also because, their shopping cart contents are fully intact and not destroyed. So I'm arriving at the conclusion that these session timeouts are not being triggered by the slamming code.

I can only sporadically reproduce this issue, so I'm having a very difficult time figuring out what sequence of actions causes this particular behavior by Zen-Cart.

I've looked at other sources of session timeout issues, such as Suhosin, and I've contacted my webhost. We reviewed the phpinfo of my server, and suhosin encrypt sessions is set to OFF both locally and globally.

From my observations, it appears that there is some kind of session mismatching occurring (I'm sorry if i'm not describing this correctly, as I'm very limited in my knowledge of php)...but right when the session timeout occurs when I hit the button to "confirm order", a zenid is attached to the end of the webaddress in the web browser's bar (which I know is normal and expected) and it's basically impossible for me to log in again on consecutive attempts, and each attempt that I'm making, attaches a new randomly generated zenid code to the end of the webaddress. This leads me to believe that the cookie session for my account is still active in the web browser's cache, but for some reason Zen-Cart is not in "sync" with that session cookie and so my web browser tries to create a new session, but needs to do so using the method of attaching a zenid to the web address. But since from the serverside, I still appear to be logged in, zen-cart won't allow me to successfully log into my account, hence a login loop occurs? It's almost the same symptom as when I log into my account from Chrome browser, then while that's still active, I try to log into my account with IE...obviously I can't and shouldn't be able to log in twice with the same account.

The only definitive way for me to successfully log back in is to close my web browser, then reopen it, and log in, and my shopping cart contents are intact (which again is what makes me believe it's not the cc slamming code causing the timeouts).

I hope my explanation and logic somewhat makes sense, and if not I apologize, but everything else I explained about how the session timeouts occur are accurate.

The nature of my store is that I am wholesale, and so my customers spend a good deal of time building their shopping carts before checking out, so yes, I know session timeouts can occur due to possible inactivity, but those timeouts should occur right at that moment that 20 minutes of idle time has occurred and not specifically on the order confirmation page, right? I know and understand the simple workaround is to let my customers know to close their web browser and try again, but it's disconcerting to the enduser for them to submit their payment information and then it throws them a session timeout message, because at that point, it's very unclear to them if the payment was actually processed. I'd rather really try to fix this solution rather than work around it.

If you have any suggestions for me to turn on any kind of logs to debug the issue, or have any additional ideas as to what might be causing these timeouts during order confirmation, I would greatly appreciate it! Meanwhile I will try to keep trying different things to narrow down the specific behavior that causes Zen-cart to time out like this. Thanks!

[DrByte]

Given the updated information about the symptoms you're encountering, I agree with you that it's not the CC slamming detection that's causing it.

And while several things you said about session stuff are not fully accurate, you are correct that there's some mismatch happening between the session data in the store vs in the customer's browser, hence the logout.

A detailed list of your addons/customizations, especially but not limited to things related to checkout, will be helpful. (see the Posting Tips window when you click Reply below).
And turning on PayPal Debug Logging would be helpful too: http://www.zen-cart.com/showthread.p...Logging-PayPal

[RoboPhung]

Hi Dr. Byte,

So I have the following mods:

Admin Login as Customer
Ceon URI Mapping
Maxmind
QueryCache
Fast and Easy Checkout
Product Attribute Grid
Stock by Attributes
Quantity Discounts
Super Orders
Ty Package Tracker
SiteMapXML
Google Analytics

I'm currently running PHP 5.3 in FastCGI mode.

I'm using a nonshared secured certificate, and my sessions are configured to run in database mode.

Here are my sessions configuration in the admin:

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- True
IP to Host Conversion Status- true
Use root path for cookie path- False
Add period prefix to cookie domain- True

I began by switching my website to 5.3 CGI instead of FastCGI...not sure if that might help, but so far, I have not been able to trigger the session timeout.

If I can successfully get the checkout process to timeout, my guess is the addon that i have to start off with isolating as a potential cause of this behavior by Zen-Cart is FEC?

I've turned on the PayPal logs, but nothing to report as of yet...Any additional input or help you can offer would be greatly appreciated it. Thank you so much!

[RoboPhung]

Ok so I believe I've pinpointed the exact cause of the problem.

So basically, if i am logged in as a customer, and at any point during my session while building my shopping cart, if I go idle and I am timed out...once I log back in, everything appears fine and I can continue to shop, but the moment I attempt to check out, and hit the final button to "confirm order" I get thrown into a session timeout loop.

So somehow there is some kind of mismatch or disconnect between client session and server session in this particular situation right when submitting payment information for processing.

This also explains why I'm hitting an unusual number of customers complaining to me about this issue, since my store format is wholesale and customers can potentially load their shopping cart up with numerous products, they can take up to an hour or more to build and finalize their shopping cart. There is a high probability that they might go afk at some point during their shopping and come back to find themselves logged out, but when they log back in to continue shopping and checkout, the session timeout loop occurs.

The problem seems to be resolved only when closing the web browser entirely and reopening it, logging in, and attempting checkout again.

I tested this both on IE9 and chrome and the same thing occurs.

I am not sure if this issue exists in vanilla 1.3.9h without any additional modules added in, as I have not had the time to run further tests into that much detail. I'll roll back an earlier backup of my store into a test subdomain and try to see if this issue still exists, as soon as I can but Dr. Byte, if you have a test server all set up already, and handy to test this scenario out, perhaps you can help me run a quick test on this scenario at your convenience? Thank you so much for all the assistance you provide on a daily basis to everyone.

[RoboPhung]

So my webhost changed some security settings on their end (the details of which I am not sure of), and that appears to have resolved my session timeout issues in my specific scenario. Everything's working great now. Problem solved!

[DrByte]

So my webhost changed some security settings on their end (the details of which I am not sure of), and that appears to have resolved my session timeout issues in my specific scenario. Everything's working great now. Problem solved!

Any chance you can drag those details out of them? It might be quite helpful for others in the future.

[RoboPhung]

I had spoken too soon about what I thought was the solution...as the problem crept up again, and I was able to trigger it.

I messed around in my admin and changed "check ssl session id" to true (that being the only change) and so far it also seems to be holding up, and passing all my attempts to trigger the timeouts...but I'll need to test more comprehensively before preemptively suggesting that it's a working solution.