Whoops! Your session has expired.

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

[DrByte]

It would be rare for that to be the "fix".

[dochsa]

Hi All I am suddenly having the same issue. Evenytime I click on Checkout, the session seems to time out? Any help is appreciated. This has happened over night and Im unsure as to what has happened.

Site: www.assceneon.com/catalog

Donovan

[GerryTheMole]

I have had this issue with 1.3.9h and the Cardsave module from Ceon. I found the slamming code and it is actually set to THREE attempts not SIX. (I have checked the 1.5.1 code and the same applies). BUT!! and like me it's a big but! If you encounter 3d (secured by visa or whatever you know it as) the attempt count halves. You now have 1.5 attempts so you make 1 mistake - and people do - and when you try the 3d secure second time you have already used you full quota. By upping the attempt count to SIX I then find I get a genuine 3 attempts with 3d but, obviously, six without 3d.

[IndyNeal]

I am having the exact problems that RoboPhung described. Version 1.51

Just wanted to follow up and see if he's still here and to confirm that his fix worked.

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.

[RoboPhung]

I am having the exact problems that RoboPhung described. Version 1.51

Just wanted to follow up and see if he's still here and to confirm that his fix worked.

No, it's not a fix. You should probably leave it the way it is by default.

I also don't believe it's a session mismatch causing it either, but rather something in the actual code that's making a specific call to kill the session due to the data received back from PayPal at the time the credit card information is sent to be verified.

You should be certain of a few things however, before you can be certain that you have this same issue that I've been experiencing. There are several other things that can cause session timeouts which is normal and not considered a bug.

1. This is not the normal credit card slamming protection that is built into the code. The default is 3 attempts to submit payment, but for the slamming detection to actually be triggered, the payment attempt must have reached all the way to the confirmation page. And if you turned on email debugging notification in the paypal pro payments module settings, you will receive an email for each time the attempt failed. After 3, the session is killed, the customer receives the "Whoops, session timed out" message screen, and their shopping cart contents are completely destroyed.

2. Your webhost's mysql session timeouts are typically set as default at 20 minutes. If the customer is logged in and happen to let their pc idle for 20 minutes or more and come back to try to continue shopping or make their payment, the session is timed out, and they also get a whoops message. It's hard to predict customer behavior, but you'd be surprised at how many people leave their computers for 20 minutes at the checkout screen and then come back to submit their payment and panic because they're not sure if the credit card was actually processed or not. I get several customers who contact me about this each month. You might want to contact your webhost to have them set the timeout at a longer period than 20 minutes if that is the main source of your problem.

The specific issue I had was that none of the above two were met, but in some situations where the customer was in the process of checking out, they may have inputted the wrong credit card number on a few attempts (i.e., inputting 15 digits instead of 16, or misstyped their credit card number) and when it reaches the 3rd checkout, hitting the "confirm order" button immediately logs them out and they get hit with the whoops message. I, too, was also able to replicate this issue on my clean upgrade to 1.51, but it was indeed hard for me to replicate the exact set of conditions to do so (I had to enter a completely wrong credit card number maybe 10+ times in a row to get it to tirgger) but I knew it still persisted because I got a few customers who yet again described that they hit the confirm order button and got hit with session timeouts, and were worried about their cc being charged, but I logged into their accounts and their shopping cart contents were not destroyed. This was after I upgraded to 1.51.

So I've narrowed down the code to where a specific function in the paypaldp payment module (for payments pro) makes a call to kill the session depending on the arguments received back from paypal concerning the payment information being submitted, and I disabled that function. Unfortunately, I'm testing this in my live store, since I don't have another spare SSL set up in a test environment, but it looks promising so far. I have not been able to replicate my issue since, granted I have not tested extensively, and payments are still being processed smoothly.

I'm no php expert, but from my limited abilities, I can't see how disabling that function in question would break any feature anyway, and the best litmus so far is that I have not received any customer complaints.

I'm not at my main pc at the moment, so I can't share my findings until I get home. But I'll let you know what i did as soon as i can, and hopefully that will fix your problem too....and also hopefully, someone much more knowledgeable, like Dr. Byte, can chime in and explain if I might have found a fix to the problem, or if the change I made is actually detrimental in some way.