Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24
  1. #11
    Join Date
    Apr 2008
    Location
    United Kingdom
    Posts
    62
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    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

  2. #12
    Join Date
    Dec 2008
    Posts
    57
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    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.

  3. #13
    Join Date
    Nov 2011
    Location
    Indianapolis, IN
    Posts
    7
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    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.

  4. #14
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    Quote Originally Posted by IndyNeal View Post
    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.

  5. #15
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    Okay so I traced the issue backwards beginning from where I can see the session timeout error begins. Normally hitting the "confirm order" button would lead us to the checkout success page and the order is inputted into the zen-cart system.

    So looking at the "includes\modules\pages\checkout_success\header.php" file, referencing line 16...

    PHP Code:
    if (!$_SESSION['customer_id']) {
      
    zen_redirect(zen_href_link(FILENAME_TIME_OUT));

    We get directed to the "Whoops, your session timed out" message when the session customer id variable is UNSET.

    Now looking at the "includes\modules\payment\paypaldp.php" file, referencing line 1748...

    PHP Code:
    function ec_delete_user($cid) {
        global 
    $db;
        unset(
    $_SESSION['customer_id']);
        unset(
    $_SESSION['customer_default_address_id']);
        unset(
    $_SESSION['customer_first_name']);
        unset(
    $_SESSION['customer_country_id']);
        unset(
    $_SESSION['customer_zone_id']);
        unset(
    $_SESSION['comments']);
        unset(
    $_SESSION['customer_guest_id']);
      } 
    You can see that indeed a function exists within this module that UNSETS the customer_id variable of a current customer session...

    Now here is the interesting thing about this function -- the comment for the function describes it as follows:

    /**
    * If the account was created only for temporary purposes to place the PayPal order, delete it.
    */

    I can't think of any scenario where an account could only be temporarily created to place an order using their credit card inputted directly on the zen-cart website (Website Payments Pro method).

    There is no possible way for this to happen, the customer must create a permanent account first, unless the zen-cart administrator implemented COWOA for their store?? But that's an entirely different module, which I'm not familiar with at all, and I don't think has anything to do with this particular function in question.

    Furthermore, this function only UNSETS most of a session's variables, it doesn't actually delete the customer's account. If you reference the function as it's defined in the PayPal Express payments module (paypalwpp.php), that function definition actually deletes the customer entirely from the zen-cart database in addition to UNSETTing all the session variables. I haven't familiarized myself too much with PayPal express checkout, but I know in the PayPal express checkout module settings we can choose whether or not to automatically create accounts, so I'm assuming that it is indeed possible for customers to shop as guests, check out with PayPal and have their account details destroyed from the zen-cart database after checkout completes. That seems fine and a proper implementation for the flow of a PayPal Express Checkout transaction, but this simply isn't possible when we are talking about Website Payments Pro.

    This leads me to believe that this function might just be old deprecated code that carried over somehow, and it does not really have any place in the way the paypaldp.php payment module should function.

    Now to further work backwards, I took a look at what other function actually makes a call to "ec_delete_user()". It begins only a few lines down starting at 1770...

    PHP Code:
    if ($kill_sess_vars) {
          if (!empty(
    $_SESSION['paypal_ec_temp'])) {
            
    $this->ec_delete_user($_SESSION['customer_id']);
          }
          
    // Unregister the paypal session variables, making the user start over.
          
    unset($_SESSION['paypal_ec_temp']);
          unset(
    $_SESSION['paypal_ec_token']);
          unset(
    $_SESSION['paypal_ec_payer_id']);
          unset(
    $_SESSION['paypal_ec_payer_info']);
          unset(
    $_SESSION['paypal_ec_final']);
          unset(
    $_SESSION['paypal_ec_markflow']);
          
    // debug
          
    $this->zcLog('termEC-1''Killed the session vars as requested');

    I took a look at exactly how $kill_sess_vars could be defined as 'true' and it comes down to another variable called $gateway_mode being passed to the TerminateEC() function call.

    So finally I looked at how $gateway_mode is defined and on line 1801 it is defined as...

    PHP Code:
    $gateway_mode = (isset($response['PNREF']) && $response['PNREF'] != ''); 
    I don't really have any understanding as to what the $response['PNREF'] response code from PayPal means, but I'm presuming that it is indeed possible for that response code to come back as defined which leads to a sequence of functions being executed that eventually leads the customer to the session timeout problem.

    My best conjecture is that some specific triggers can lead to the PNREF response code from PayPal to unintentionally come back as not NULL which is the root of this problem, and my workaround was to comment out part of the "ec_delete_user()" function, because, as I had explained above, it doesn't appear as if this function has any place in the implementation of this payment module.

    Specifically:

    PHP Code:
    if ($kill_sess_vars) {
          
    /* Begin RoboPhung Edit
          if (!empty($_SESSION['paypal_ec_temp'])) {
            $this->ec_delete_user($_SESSION['customer_id']);
          }
          End RoboPhung Edit */
          // Unregister the paypal session variables, making the user start over.
          
    unset($_SESSION['paypal_ec_temp']);
          unset(
    $_SESSION['paypal_ec_token']);
          unset(
    $_SESSION['paypal_ec_payer_id']);
          unset(
    $_SESSION['paypal_ec_payer_info']);
          unset(
    $_SESSION['paypal_ec_final']);
          unset(
    $_SESSION['paypal_ec_markflow']);
          
    // debug
          
    $this->zcLog('termEC-1''Killed the session vars as requested');
        } 
    So far, this does not appear to have created any issues for my customer's transactions, and I myself, have not been able to trigger any session timeout problems after repeated tests. But of course, and it should go without saying, I should state a disclaimer that you should thoroughly test it out yourself before going "live" with the code change if you have the same problem as me and think that this might help solve it.

  6. #16
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    Just relooked over my last post and realized that the source of the issue might be the inner nested IF statement of the terminateEC() function...

    PHP Code:
    if ($kill_sess_vars) { 
          if (!empty(
    $_SESSION['paypal_ec_temp'])) { 
            
    $this->ec_delete_user($_SESSION['customer_id']); 
          } 
          
    // Unregister the paypal session variables, making the user start over. 
          
    unset($_SESSION['paypal_ec_temp']); 
          unset(
    $_SESSION['paypal_ec_token']); 
          unset(
    $_SESSION['paypal_ec_payer_id']); 
          unset(
    $_SESSION['paypal_ec_payer_info']); 
          unset(
    $_SESSION['paypal_ec_final']); 
          unset(
    $_SESSION['paypal_ec_markflow']); 
          
    // debug 
          
    $this->zcLog('termEC-1''Killed the session vars as requested'); 

    Specifically, (!empty($_SESSION['paypal_ec_temp'])), paypal_ec_temp is set by the paypal express checkout module. So my assumption is that a customer might begin a PayPal payment, but decide to cancel and return to the checkout page to complete the checkout by credit card instead. And under certain circumstances, whether paypal_ec_temp is assigned as TRUE or FALSE by the paypalwpp express checkout module, it never gets UNSET, so thus (!empty($_SESSION['paypal_ec_temp'])) returns a true value.

    I restored the original unmodified paypaldp.php payment module and tested as follows:

    Begin a checkout by PayPal, cancel at the PayPal page and get returned to the store. Then proceed to enter an incorrect creditcard number 8 times in a row (not an actual accepted credit card number that actually allows us to reach the confirm order page, but an incorrect creditcard number by which the message stack returns the message: The credit card number entered is invalid. Please check the number and try again.)

    Then finally enter the correct credit card information and get hit with a session timeout. So I can confirm that this glitch still exists in 1.51.

    I reverted back to the paypaldp.php module with my changes as described in the previous post, and followed the same sequence again, and the order was successfully processed after 8 bad creditcard info attempts.

    I know my test scenario is extreme, and it would be unreasonable to expect customers would ever reach those lengths to trigger this session timeout problem, but I know that this glitch does get triggered in live scenarios, as I've encountered in the past, several customers a month would call me and tell me about getting the timeout message when attempting to check out, and assured me that they did not let their PC idle for any lengthy period while shopping. So perhaps it only takes 1-2 incorrect credit card entries and at some point the customer also attempted to checkout by PayPal but decided not to.

    Whatever the case may be, like I said, it really does not appear as if ec_delete_user() function has any real meaningful reason to exist in this module, because it's purpose appears to be to log an individual out of their zen-cart session if the account was created only for temporary purposes of placing the order, which is not applicable when a customer decides to pay directly with credit card through website payments pro.

    If it can be confirmed as indeed a bug, then perhaps I should look into submitting it in the bug reports forum.

  7. #17
    Join Date
    Nov 2011
    Location
    Indianapolis, IN
    Posts
    7
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    This is SO FRUSTRATING.

    I've tried the fixes that RoboPhung has made, seemingly successfully on his site, however we are still experiencing this same problem.

    As RoboPhung has with great detail described his problem, ours is pretty much exactly as his.

    We are experiencing this with customers about once or twice for every 20 orders or so. It only happens sometimes. I've even gone in an submitted test orders over and over and they'll work, then bam I'll get the "whooops you're session" has timed out. I, personally, have been able to re-log in (after closing browser) and submit an order, however, some customers get caught in a perpetual "whoops" loop where they can not get an order to go through. They call, I log into their account and submit the order with no problem.

    The hard part here is that it only happens sometimes. I talk to the customers, they are seemingly not doing anything that should cause the time out to happen. They browse catalog, register go to payment all in just a couple of minutes and they are still "timed out".

    All of this happens right at the end at checkout when users submit their orders.

    Just like RoboPhung we use Paypal Payments Pro as our merchant provider. Is this a Paypal issue or is this all inside Zencart? As I said, I made the changes RoboPhung did and we still experience with problem.

    I'm tempted to set up another merchant account with Authorize.net to see if the problem continues there.

    Any other thoughts?

  8. #18
    Join Date
    Apr 2009
    Posts
    15
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    I have the same problem. Just upgraded to 1.5.1. If a customer is IDLE for sometime, when trying to checkout they get the Woops! message. The customer has to refresh its cart (adding or deleting a product), then they can continue through the checkout process. I've followed this thread but there is no a specific solution mentioned.

    Please help Dr. Byte

  9. #19
    Join Date
    Jan 2004
    Posts
    66,364
    Blog Entries
    7
    Plugin Contributions
    274

    Default Re: Whoops! Your session has expired.

    Quote Originally Posted by ZCricardo View Post
    If a customer is IDLE for sometime
    When the customer is idle, a timeout naturally occurs when their session expires. This is not new.
    You didn't say what payment method is involved in your scenario, if any.
    You also didn't list any of the ways in which your store is different from original ZC code.
    .

    Zen Cart - putting the dream of business ownership within reach of anyone!
    Donate to: DrByte directly or to the Zen Cart team as a whole

    Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
    Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.

  10. #20
    Join Date
    Apr 2009
    Posts
    15
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    Quote Originally Posted by DrByte View Post
    When the customer is idle, a timeout naturally occurs when their session expires. This is not new.
    You didn't say what payment method is involved in your scenario, if any.
    You also didn't list any of the ways in which your store is different from original ZC code.
    Ok, the customer is IDLE, but the only way to be able to do the checkout process, even after loggin again, is refreshing the cart as I described. There is no additional code just the 1.5.1 that I downloaded. The client hasn't selected payment method because the message is shown as soon as the customer clicks the checkout button.

    In 1.3.8a this was not an issue

    Thanks!

 

 
Page 2 of 3 FirstFirst 123 LastLast

Similar Threads

  1. 1.5.4 Whoops! Your session has expired.
    By marcopolo in forum General Questions
    Replies: 15
    Last Post: 20 Jul 2015, 01:10 PM
  2. v137 Whoops! Your session has expired. Session Question.
    By weblamer in forum Upgrading to 1.5.x
    Replies: 5
    Last Post: 7 Jun 2015, 07:20 PM
  3. v151 Whoops! Your session has expired.
    By Palladium in forum Built-in Shipping and Payment Modules
    Replies: 5
    Last Post: 26 Jan 2015, 07:24 PM
  4. Whoops! Your session has expired
    By loganwest in forum General Questions
    Replies: 15
    Last Post: 31 Mar 2014, 01:49 PM
  5. Whoops! Your session has expired
    By stagebrace in forum General Questions
    Replies: 2
    Last Post: 30 Sep 2009, 03:14 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
disjunctive-egg
Zen-Cart, Internet Selling Services, Klamath Falls, OR