Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Sessions being randomly lost


Bryce F

Recommended Posts

The website:

http://watermelonmusic.x10hosting.com/osc/

 

The problem:

After navigating around the website for a little (especially if using the browser forward/back buttons), the user session is lost. No particular actions of lengths of time trigger this - it seems like (un)luck. This happens for both guests and registered members.

 

A tangentially related issue:

I recently started getting an error in includes/classes/navigation_history.php around line 130.

   function filter_parameters($parameters) {
     $clean = array();
     reset($parameters);

     while (list($key, $value) = each($parameters)) {
       if (strpos($key, '_nh-dns') < 1) {
         $clean[$key] = $value;
       }
     }

     return $clean;
   }

Apparently, $parameters spits out an invalid array during the checkout process. I var_dump'ed it, and it looks valid, except for some reason there's a NULL first entry, and the reset() function was crashing. Additionally, the while/each loop was crashing when it hit the first NULL entry in the array. I ended up commenting out everything but $clean = array(); and return $clean; , and now the checkout works correctly.

 

Not sure if this was relevant. The random session reset/loss has been happening for some time now, but this last modification I made seemed to increase the frequency.

 

Any ideas? Thanks!

 

Feel free to mess around with the website and register with fake info, if it helps.

Link to comment
Share on other sites

The problem:

After navigating around the website for a little (especially if using the browser forward/back buttons), the user session is lost. No particular actions of lengths of time trigger this - it seems like (un)luck. This happens for both guests and registered members.

I don't get the impression the session is lost (the session id stays the same) but the shopping cart is indeed randomly emptied.

 

There have been a lot of reports of the navigation history object getting corrupted when there is a code error somewhere. It doesn't get restored/reset then and you get the same error everytime (fatal error call to a member function on a non-object bla, bla) and the site cannot be reached anymore until you remove you cookie from the site (there is a fix for this particular error in the thread mentioned by dynamoeffects).

So far I have not seen a report of how to replicate this particular problem so that is a bit of a problem.

 

Now your problem looks to be something different but I wonder if there is not a PHP error or PHP warning somewhere (not shown to the customer) that might be the root cause of it?

Link to comment
Share on other sites

Thanks for the reply,

 

I don't get the impression the session is lost (the session id stays the same) but the shopping cart is indeed randomly emptied.

Well, when a customer logs in, the random error will cause him to log out (session is lost I presume). However, his shopping cart will be saved and repopulates when he logs back in. I think it's likely a session issue, but I'm not sure how to test this.

 

There have been a lot of reports of the navigation history object getting corrupted when there is a code error somewhere. It doesn't get restored/reset then and you get the same error everytime (fatal error call to a member function on a non-object bla, bla) and the site cannot be reached anymore until you remove you cookie from the site (there is a fix for this particular error in the thread mentioned by dynamoeffects).

So far I have not seen a report of how to replicate this particular problem so that is a bit of a problem.

I went ahead and implemented the change mentioned at the end of that thread, and then undid the commenting I'd mentioned in navigation_history.php. This seemed to help to some degree, though the problem is still happening. I believe the fix you'd mentioned prevents PHP from crashing if the navigation history object is invalid. I still have no idea what's causing the object to be invalid in the first place. But I wonder if it's possible to take that invalid object (which seems to be off only by a NULL in the beginning) and rectify it. I'm not sure if the object is an array in the format of:

{ NULL , history_attribute_1, history_attribute_2, etc... }

or in the more annoying form of:

{ NULL , { original history array } }

 

Now your problem looks to be something different but I wonder if there is not a PHP error or PHP warning somewhere (not shown to the customer) that might be the root cause of it?

Currently I have all php errors displaying (to the customer). I'm not sure how to track errors or warnings outside of this...

Link to comment
Share on other sites


I believe the fix you'd mentioned prevents PHP from crashing if the navigation history object is invalid.

Yes, but the problem usually arises due to an error somewhere.

I'm not sure if the object is an array in the format of:

{ NULL , history_attribute_1, history_attribute_2, etc... }

or in the more annoying form of:

{ NULL , { original history array } }

Perhaps you can see that when you echo it in your footer (change last lines to read):

<?php
 }
 echo '<!-- <pre>Navigation history<br>';
 print_r($navigation);
   echo '</pre> -->';
?>

If you do a view source you should see something like:

Navigation history
navigationHistory Object
(
   [path] => Array
       (
           [0] => Array
               (
                   

 => index.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [cPath] => 1_6
                       )

                   [post] => Array
                       (
                       )

               )

           [1] => Array
               (
                   

 => advanced_search_result.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [keywords] => bug
                           [x] => 6
                           [y] => 8
                       )

                   [post] => Array
                       (
                       )

               )

       )

   [snapshot] => Array
       (
       )

)

Link to comment
Share on other sites


Thank you for the help so far! I just did a print_r($navigation) before and after the logout / lost session, and it doesn't appear to have an invalid history object. I believe a few of the fixes we'd discussed earlier in this thread may have cleaned up invalid history objects, but the logout/lost session is happening regardless. The frequency of the error is much less now, but it still concerns me that it happens.

 

The error seems disproportionately common when using the back/forward browser buttons.

 

If it's a PHP error I've made somewhere, do you know how I might trace it?

 

If you're curious, here's the dumped object before and after the error:

 

BEFORE:

navigationHistory Object
(
   [path] => Array
       (
           [0] => Array
               (
                   

 => checkout_payment.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                       )

                   [post] => Array
                       (
                       )

               )

           [1] => Array
               (
                   

 => checkout_shipping.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                       )

                   [post] => Array
                       (
                       )

               )

       )

   [snapshot] => Array
       (
       )

)

 

AFTER:

navigationHistory Object
(
   [path] => Array
       (
           [0] => Array
               (
                   

 => login.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                       )

                   [post] => Array
                       (
                       )

               )

       )

   [snapshot] => Array
       (
       )

)
Link to comment
Share on other sites

...Bump...

 

Website: http://watermelonmusic.x10hosting.com/osc/

 

Forward/Back browser buttons (likely) cause lost sessions. Logged-in members are randomly logged out. Guests (but not members) lose their shopping carts.

 

I believe it's a lost session, but not sure how to test this. If it's due to an invalid navigationHistory object and I wrote some bad PHP code somewhere corrupting this, how would I trace it?

 

I really appreciate the help so far. Jan, so far you've helped me eliminate at least 70% of the lost sessions.

 

(Sorry, I promise this will be the one and only bump)

Link to comment
Share on other sites

I believe it's a lost session, but not sure how to test this. If it's due to an invalid navigationHistory object and I wrote some bad PHP code somewhere corrupting this, how would I trace it?

As far as I could see I did lose the shopping cart (not logged-in) but the osCsid stayed the same. No clue where this is coming from but personally I would look carefully into application_top.php and the class shopping_cart.php.

Link to comment
Share on other sites

I recon it's an osCommerce gremlin that's added the following code : -

 

  if ( false !== $i_feel_like_it ) {
   $cart->reset( true );
 }

 

Sorry, I'll get my coat <leaves quickly>

Link to comment
Share on other sites

As far as I could see I did lose the shopping cart (not logged-in) but the osCsid stayed the same. No clue where this is coming from but personally I would look carefully into application_top.php and the class shopping_cart.php.

 

I don't think it has anything to do with the shopping cart actually. I just created a test account. If you have a moment, please log in with:

user: [email protected]

pw: 12345

 

If you log in, then browse around without adding anything to the cart or even viewing an item, you can produce the error. Just hit forward and back a few times and you will be logged out. If it's not the session id, what would cause this behavior?

 

Thanks!

Link to comment
Share on other sites

I don't think it has anything to do with the shopping cart actually. I just created a test account. If you have a moment, please log in with:

user: [email protected]

pw: 12345

 

If you log in, then browse around without adding anything to the cart or even viewing an item, you can produce the error. Just hit forward and back a few times and you will be logged out. If it's not the session id, what would cause this behavior?

 

Thanks!

 

I just took another look and it seems to be nothing to do with the browser buttons. If you log in then go to the home page and stay there and refresh every 10 seconds it eventually logs you out .. it is probably a consistent time but i do not have a stopwatch.

 

Perhaps someone tried to add a session life to the script and fudged it? have you tried comparing includes/functions/sessions.php to a fresh file?

Link to comment
Share on other sites

I just took another look and it seems to be nothing to do with the browser buttons. If you log in then go to the home page and stay there and refresh every 10 seconds it eventually logs you out .. it is probably a consistent time but i do not have a stopwatch.

 

Perhaps someone tried to add a session life to the script and fudged it? have you tried comparing includes/functions/sessions.php to a fresh file?

 

I did some similar testing just now. It doesn't seem to be based on time, but is more likely correlated with number of page requests. I tried navigating to both random pages and to the same repeated page. I tried various time intervals between clicks. What I noticed is that it errors after about 5 clicks/refreshes regardless of time. Standard deviation of about 1 click.

 

I can't check the source code now until I get home, but will check later...

Link to comment
Share on other sites

Ok, I've checked my includes/functions/sessions.php and it looks vanilla to me. I did a bit of probing in this file and noticed some behavior...

 

At line 101, there is a function tep_session_register($variable). (This function will take a $variable of 'customer_id' when a login happens). I rigged it so the first line in this function would be die("fail");, so that I would see "fail" on my screen when there was a session change or modification. As per my suspicion, when the member is randomly logged out, the die() triggers. I followed up by replacing die('fail') with print_r($_SESSIONS);, and indeed the entire session was wiped. I suspected as much.

 

Any idea where to go from here. What would cause the session to be lost, and how could I possibly backtrace to it?

Link to comment
Share on other sites

Ok, I've checked my includes/functions/sessions.php and it looks vanilla to me. I did a bit of probing in this file and noticed some behavior...

 

At line 101, there is a function tep_session_register($variable). (This function will take a $variable of 'customer_id' when a login happens). I rigged it so the first line in this function would be die("fail");, so that I would see "fail" on my screen when there was a session change or modification. As per my suspicion, when the member is randomly logged out, the die() triggers. I followed up by replacing die('fail') with print_r($_SESSIONS);, and indeed the entire session was wiped. I suspected as much.

 

Any idea where to go from here. What would cause the session to be lost, and how could I possibly backtrace to it?

So that's where the "fail" came from!

:lol:

 

I was clicking around on the site checking the osCsid in the cookie with Firefox Webdeveloper plugin.

 

It remains the same even after the cart gets dumped (I never created an account and logged in).

 

I don't know if that helps at all but I thought I'd toss that in.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Link to comment
Share on other sites

So that's where the "fail" came from!

:lol:

 

I was clicking around on the site checking the osCsid in the cookie with Firefox Webdeveloper plugin.

 

It remains the same even after the cart gets dumped (I never created an account and logged in).

 

I don't know if that helps at all but I thought I'd toss that in.

 

Well, I hope it's not still displaying "fail"...

 

I created a test account: [email protected] / 12345

 

Feel free to have a look :D

Link to comment
Share on other sites

Well, I hope it's not still displaying "fail"...

 

I created a test account: [email protected] / 12345

 

Feel free to have a look :D

Naw.. The "fail" isn't there but the problem still is.

:'(

 

I used the test account and kept track of the osCsid in the cookie.

 

It stayed the same even after the cart got dumped and I was logged out (after only about 1/2 dozen clicks).

 

Maybe Jan or Robert will have some suggestions.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Link to comment
Share on other sites

I had a thought... is it possible that the way my webserver is configured could be the culprit? Perhaps something related to SSL?

The site doesn't use SSL that I could see. At least it never tried to for me.

If I suggest you edit any file(s) make a backup first - I'm not perfect and neither are you.

 

"Given enough impetus a parallelogramatically shaped projectile can egress a circular orifice."

- Me -

 

"Headers already sent" - The definitive help

 

"Cannot redeclare ..." - How to find/fix it

 

SSL Implementation Help

 

Like this post? "Like" it again over there >

Link to comment
Share on other sites


I used the test account and kept track of the osCsid in the cookie.

 

It stayed the same even after the cart got dumped and I was logged out (after only about 1/2 dozen clicks).

 

I did some cookie snooping too just now. Seems that osCommerce does not use cookies for guests anyhow. Essentially, when the test user's session was dropped, you were seeing the old osCsid from earlier. The cookie was not updated to reflect the lost session. In fact, if you log back in with the test user, you should get a new osCsid in your cookie. Please correct me if I'm wrong...

 

I still think something is probably causing the session to die. Just wish I knew how to determine what that something is... >_<

 

EDIT: Hmm... why is it about 5-6 clicks before the session biffs? Is is possible that too long of a history is corrupting the session and resetting it? I explored the navigationHistory object earlier... wonder if I didn't look at that thoroughly enough...

 

EDIT 2:

I deleted the session cookies and dumped the navigationHistory object. Seems removing the cookies put the object into a more verbose mode. Here is the object before and after the crash. Note that the session IDs are the same...???

 

BEFORE:

navigationHistory Object
(
   [path] => Array
       (
           [0] => Array
               (
                   

 => advanced_search.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [osCsid] => 2318f2797818072ca2819bf454d494cd
                       )

                   [post] => Array
                       (
                       )

               )

           [1] => Array
               (
                   

 => login.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [action] => process
                           [osCsid] => 2318f2797818072ca2819bf454d494cd
                       )

                   [post] => Array
                       (
                           [email_address] => [email protected]
                           [password] => 12345
                           [x] => 38
                           [y] => 10
                       )

               )

           [2] => Array
               (
                   

 => index.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [osCsid] => 2318f2797818072ca2819bf454d494cd
                       )

                   [post] => Array
                       (
                       )

               )

           [3] => Array
               (
                   

 => advanced_search_result.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [type] => season
                           [osCsid] => 2318f2797818072ca2819bf454d494cd
                       )

                   [post] => Array
                       (
                       )

               )

       )

   [snapshot] => Array
       (
       )

)

 

AFTER:

navigationHistory Object
(
   [path] => Array
       (
           [0] => Array
               (
                   

 => advanced_search_result.php
                   [mode] => NONSSL
                   [get] => Array
                       (
                           [type] => season
                           [osCsid] => 2318f2797818072ca2819bf454d494cd
                       )

                   [post] => Array
                       (
                       )

               )

       )

   [snapshot] => Array
       (
       )

)
Link to comment
Share on other sites

I did some cookie snooping too just now. Seems that osCommerce does not use cookies for guests anyhow.

 

Guests have cookies just like logged in customers.

 

 

Essentially, when the test user's session was dropped, you were seeing the old osCsid from earlier. The cookie was not updated to reflect the lost session. In fact, if you log back in with the test user, you should get a new osCsid in your cookie. Please correct me if I'm wrong...

 

If regenerate session is set to true in admin.

 

I deleted the session cookies and dumped the navigationHistory object. Seems removing the cookies put the object into a more verbose mode.

 

It's not more verbose, it is just that prior to the session dropping the navigation history was populated with previously visited pages .. after .. just the one, the current page.

Link to comment
Share on other sites

Are other session variables also getting lost.

Also check the sql error log.

 

Satish

Ask/Skype for Free osCommerce value addon/SEO suggestion tips for your site.

 

Check My About US For who am I and what My company does.

Link to comment
Share on other sites


Are other session variables also getting lost.

Also check the sql error log.

 

There were no MySQL errors.

 

Session variables seem to be resetting too. Below is a dump of $_SESSION before and after the crash. Note that the crash clears out most of the session variables. Even more interesting perhaps is that from the query log, we can see the sesskey changes. I noticed that the sesskey remains constant until the crash happens - at this point a new one is generated!

 

Ideas?

 

 

BEFORE:

Array
(
   [qlog] => (0.00048 secs):<br />select value from sessions where sesskey = 'f56fc0204879268e8b45523a3b46e057' and expiry > '1261016918'<br /><br />.....
       .....[REMAINDER OMITTED BY BRYCE: Very long; Doesn't seem particularly interesting.]
   [questions] => 364
   [cart] => shoppingCart Object
       (
           [contents] => Array
               (
                   [PM2417161R] => Array
                       (
                           [qty] => 1
                       )

               )

           [total] => 0
           [weight] => 0
           [cartID] => 
           [content_type] => 
       )

   [language] => english
   [languages_id] => 1
   [currency] => USD
   [navigation] => navigationHistory Object
       (
           [path] => Array
               (
                   [0] => Array
                       (
                           

 => index.php
                           [mode] => NONSSL
                           [get] => Array
                               (
                               )

                           [post] => Array
                               (
                               )

                       )

                   [1] => Array
                       (
                           

 => advanced_search_result.php
                           [mode] => NONSSL
                           [get] => Array
                               (
                                   [type] => season
                               )

                           [post] => Array
                               (
                               )

                       )

               )

           [snapshot] => Array
               (
               )

       )

   [customer_id] => 31
   [customer_default_address_id] => 34
   [customer_first_name] => Test
   [customer_country_id] => 223
   [customer_zone_id] => 12
)

 

AFTER:

Array
(
   [qlog] =>  (0.0005 secs):<br />select value from sessions where sesskey = '7d292f6fbad3d6d4fdd44bd6ed751330' and expiry > '1261017027'<br /><br />.....
       .....[REMAINDER OMITTED BY BRYCE: Very long; Doesn't seem particularly interesting.]
   [questions] => 57
   [cart] => shoppingCart Object
       (
           [contents] => Array
               (
               )

           [total] => 0
           [weight] => 0
           [content_type] => 
       )

   [language] => english
   [languages_id] => 1
   [currency] => USD
   [navigation] => navigationHistory Object
       (
           [path] => Array
               (
                   [0] => Array
                       (
                           

 => advanced_search_result.php
                           [mode] => NONSSL
                           [get] => Array
                               (
                                   [type] => season
                               )

                           [post] => Array
                               (
                               )

                       )

               )

           [snapshot] => Array
               (
               )

       )

)
Link to comment
Share on other sites

Oh and just to further show that sessions are being lost:

 

I injected another die("fail"); in application_top.php:

 

 if (tep_session_is_registered('navigation')) {
   if (PHP_VERSION < 4) {
     $broken_navigation = $navigation;
     $navigation = new navigationHistory;
     $navigation->unserialize($broken_navigation);
   } elseif (!is_object($navigation)) {
     $navigation = new navigationHistory;
   }
 } else { die("fail");
   tep_session_register('navigation');
   $navigation = new navigationHistory;
 }
 $navigation->add_current_page();

 

After doing this, "fail" appears only when the error occurs, meaning the 'navigation' session var is being unregistered. But is this the cause or the effect of the error?

Link to comment
Share on other sites

Oh my....!!!

 

I finally solved it! That was insane.

 

For anybody who cared enough to follow my rambling up until the end, you may have noticed that in my dump of $_SESSION, there was a strange field called 'qlog'. About a year ago, I was doing some MySQL query cleanups, and I needed to track which queries took the most seconds to complete over time. I foolishly decided to store every database query in a new $_SESSION variable called 'qlog' (also created one called 'questions'). Every time a page would load, 'qlog' would track every additional database query. See where this is going...?

 

I was overflowing the $_SESSION variable! After about 5 or 6 clicks, 'qlog' got so backed up that it overflowed and the session become invalid and reset!

 

I know... speechless...

 

ffffuuuuu.jpg

 

Anyhow, it works great now. Thanks for your patience everybody!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...