Page 1 of 3 123 LastLast
Results 1 to 10 of 24
  1. #1
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Whoops! Your session has expired.

    Hello,

    So I've been running tests with dummy orders on WPP which was newly implemented in my store, and once in a while, I was hit with session timeout issues while checking out and submitting my cc for payment. I didn't think anything of it at the time, but now, several of my customers have contacted me about issues with checking out and the symptoms that they describe sound the same...

    I've been running more tests and I can duplicate the issue very consistently on my store.

    Basically, to trigger the session timeout.

    -Log into my account.
    -Add items to shopping cart.
    -Initiate checkout.
    -Input an incorrect cc number the first time around... and receive an invalid cc number message from the messagestack...
    -Input the corrected cc number the 2nd time around, and hit confirm order.

    Immediately, I am hit with a session timeout, and have to log in again. Sometimes this happens in a loop, and relogging in and attempting to check out results in in more session timeouts.

    Multiple consecutive session timeouts seem to be the common thing with my customers who contacted me about having problems, as well.

    While I can't be for certain that this is the only way to trigger the session timeout, I am sure this is one way to consistently trigger it...

    My installed mods are...

    Stock by Attributes
    Product Attribute Grid
    Google analytics
    SitemapXML
    Super Orders
    Ty Package Tracker
    QueryCache

    These are the mods that have been in place when I noticed the session timeout issues.

    I have installed more mods since then:

    FEC
    Maxmind
    Ceon URI

    Is anyone else having these same problems when they follow these steps above? Or does anyone know of a solution? Thanks in advance.

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

    Default Re: Whoops! Your session has expired.

    There is a built-in "credit card slamming detection" system which logs the customer out after 6 failed attempts. This is intended to thwart attempts at testing stolen card numbers.
    Most legitimate customers are savvy enough to correctly enter their payment details in less than 6 tries. The only other time I've seen this tripped is when writing a new payment module and testing it over and over again ... which of course is exactly the sort of thing the detection is designed to stop in a real live store such as yours.
    .

    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.

  3. #3
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    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!

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

    Default Re: Whoops! Your session has expired.

    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
    .

    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.

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

    Default Re: Whoops! Your session has expired.

    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!

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

    Default Re: Whoops! Your session has expired.

    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.

  7. #7
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    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!

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

    Default Re: Whoops! Your session has expired.

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

    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.

  9. #9
    Join Date
    Jan 2011
    Posts
    65
    Plugin Contributions
    0

    Default Re: Whoops! Your session has expired.

    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.

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

    Default Re: Whoops! Your session has expired.

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

    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.

 

 
Page 1 of 3 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