AOL can't checkout cause cart empties do to redirect?

Anyone else have this issue?



I don’t have an AOL browser, so I can’t verify this bug.



I have a customer called in today complaining he can’t check out and he is using AOL.



He added items to his shopping cart, but once he clicks on checkout, this shopping cart become empty.



I think there is an issue with the way cs-cart stores sessions, cookies, and the user’s shopping cart.



My non-secure url: http://www.inkwow.com

My secure url: https://secure.inkwow.com





Customer’s Browswer:



Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; PeoplePal 3.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)





What’s interesting is that in the User Stats under Admin control, I see multiple entries for the customer with the same IP.





This is what it looks like:





10/22/2009, 11:48 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra

10/22/2009, 11:48 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra

10/22/2009, 11:48 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra

10/22/2009, 11:46 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra

10/22/2009, 11:45 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra

10/22/2009, 11:45 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra

10/22/2009, 11:43 1 99.150.164.39 / - Windows Internet Explorer 7.0 United States Extra







Guess customer tried to checkout 7 times and finally decided to call instead because he was unable to checkout.

Hmm… another customer reported the same issue today.



Shopping cart empties when clicking on checkout.

Yet another AOL user complaining about shopping cart being emptied after clicking on checkout.



10/26/2009, 17:54 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 17:01 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 16:51 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 14:07 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 13:58 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 13:54 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra





User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; SV1; .NET CLR 1.1.4322)





I’ve updated:



define(‘SESS_VALIDATE_IP’, true); // link session ID with ip address



to:



define(‘SESS_VALIDATE_IP’, false); // link session ID with ip address





I’m hoping that would fix the issue.

[quote name=‘hykit’]Yet another AOL user complaining about shopping cart being emptied after clicking on checkout.



10/26/2009, 17:54 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 17:01 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 16:51 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 14:07 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 13:58 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 13:54 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra





User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; SV1; .NET CLR 1.1.4322)





I’ve updated:



define(‘SESS_VALIDATE_IP’, true); // link session ID with ip address



to:



define(‘SESS_VALIDATE_IP’, false); // link session ID with ip address





I’m hoping that would fix the issue.[/QUOTE]



Any luck with the change?

Looks like they are`not accepting Cookies.



Programs touted such as “Norton Internet Security” can cause cookie blocking which results in re-calls for the cookies. I can’t say much more as I’m not all that familiar with AOL itself.

Another complaint from another AOL user.



Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)







I can’t believe I’m the only one reporting this issue.



This is Bullocks.



I got to look into the whole IP proxy, session, and cookie issue to figure this out.



I don’t really do Windows nor do I use AOL.



Might need to download AOL 9.1 to debug the problem.

I just notice they are all the same AOL Browser.



AOLBuild 4334.5006

[quote name=‘JesseLeeStringer’]Looks like they are`not accepting Cookies.



Programs touted such as “Norton Internet Security” can cause cookie blocking which results in re-calls for the cookies. I can’t say much more as I’m not all that familiar with AOL itself.[/QUOTE]



Nah. I think it’s because AOL is unique. AOL uses go through a proxy and their IP address changes during a session.



That’s why I told you before it might be better to track by session rather than just IP address. All because of AOL users.

I had a similar problem a while ago. The customer did not allow cookies so the cart was always empty. I ended up at one point by putting on a notice to allow cookies. Have not had the notice for a while, but maybe this is why I see some abandon carts.

Don’t think this is exclusive to AOL

A customer on AOL could have multiple IP addresses. I have seen this when viewing live tracking of people on site.

Bob

[quote name=‘pbannette’]I had a similar problem a while ago. The customer did not allow cookies so the cart was always empty. I ended up at one point by putting on a notice to allow cookies. Have not had the notice for a while, but maybe this is why I see some abandon carts.

Don’t think this is exclusive to AOL

A customer on AOL could have multiple IP addresses. I have seen this when viewing live tracking of people on site.

Bob[/QUOTE]



The issue is not that they don’t have cookies turned on.



They do have cookies turned on because they are able to add products to their shopping cart.



They would add say 4 items to their shopping cart.



However, when the click on checkout, their shopping cart which had 4 items is now empty.

Guys, it’s cookies. I have had this problem for a while on our internationally advertised website. Go to Internet Explorer and set your security settings to the max which blocks cookies. Now you can replicate the problem.

[quote name=‘Sleven’]Guys, it’s cookies. I have had this problem for a while on our internationally advertised website. Go to Internet Explorer and set your security settings to the max which blocks cookies. Now you can replicate the problem.[/QUOTE]



Of course it’s a cookie issue.



The question is not whether it’s a cookie issue.



The question is what is causing the cookie issue and why it’s occurring.



My problem is not that the customer can’t add items to the shopping cart.



My problem has nothing to do with the privacy settings.



It’s related to AOL users only.



The AOL users can add items to the shopping cart, so I know they are accepting cookies.



The problem occurs when the want to “checkout”. For some reason, they are issued a new cookie with a new session, causing their shopping cart to empty because all their products in the shopping cart was associated with the older session/cookie.

[quote name=‘hykit’]

It’s related to AOL users only.



The AOL users can add items to the shopping cart, so I know they are accepting cookies.[/QUOTE]



I understand, The issue can be replicated with security settings in IE. You don’t have to have AOL. It’s a problem with both. I haven’t seen any issues with adding items to a cart, just when checking out.



Either way, it’s a major flaw that CS-Cart should correct very soon.

[quote name=‘Sleven’]I understand, The issue can be replicated with security settings in IE. You don’t have to have AOL. It’s a problem with both. I haven’t seen any issues with adding items to a cart, just when checking out.



Either way, it’s a major flaw that CS-Cart should correct very soon.[/QUOTE]



I don’t have problems with IE users in general.



It’s specific to AOL users. All the calls I’m getting about empty shopping carts are from AOL users. It’s not just a coincidence.



I just got 2 more calls today.



Again, both AOL users.





The thing I know about AOL users is that they go through a proxy and their IP changes during the session.



I know from over 10 years of programming experience that it can throw off the sessions and cookies depending on how the shopping cart is written.



However, everyone who complained so forth seems to be limited to the browser:



AOL 9.1; AOLBuild 4334.5006





Which I find weird. Maybe that AOL build has some issues.



Maybe AOL users do have some strange privacy policy configuration and causes problems with the cookies.



I found this on other sites with common AOL users:



[url]Plus Size Clothing Fashions for Women | Generousfashions.com



[url]http://www.watchbattery.co.uk/AOL_Problems.html[/url]



[url]http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0003LQ[/url]



[url]http://www.cactusoft.com/blog_38[/url]





cs-cart guys need to look at:



[url]http://webmaster.info.aol.com/index.html[/url]

Here’s magento’s solution for AOL users



[url]Home - Magento Forums



I believe below is specific to magento and how it validates a session.





Validate REMOTE_ADDR “NO”



Validate HTTP_VIA “NO”



Validate HTTP_X_FORWARDED_FOR “NO”



Validate HTTP_USER_AGENT “YES”

Okay.



Just turn off IP Validation in the ‘config.php’ file



define(‘SESS_VALIDATE_IP’, false); // link session ID with ip address





I’ll delete all my sessions and see how that goes.



Maybe it didn’t work early because I didn’t clear out my existing sessions which are stored in the database tables.



cscart_stored_sessions & cscart_sessions



which contains the ‘_validator_data’ set to the ip address and user agent.





I’ll have my customers try it out again.



If it still doesn’t work, I’ll just turn off SESSION VALIDATION period by setting ‘SKIP_SESSION_VALIDATION’ to true.



define(‘SKIP_SESSION_VALIDATION’, true);



Less secure I guess due to session hijacking.





So the 2 steps to take:

  1. set ‘SESS_VALIDATE_IP’ to false by: define(‘SESS_VALIDATE_IP’, false);
  2. delete all existing sessions in cscart_stored_sessions & cscart_sessions

F*ck!



Here’s the problem. It’s not the IP. It’s the User Agent!



Who knew?



Remember this person:



10/26/2009, 17:54 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 17:01 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 16:51 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 14:07 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 13:58 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra

10/26/2009, 13:54 1 71.139.168.231 / - Windows Internet Explorer 6.0 United States Extra





SELECT *

FROM cscart_stored_sessions

WHERE data LIKE ‘%71.139.168.231%’





In the database ‘cscart_stored_sessions’:



83993c8a427af6ed20167bf8eb610806 1256597913 settings|a:2:{s:14:“cart_languageC”;a:2:{s:5:"valu… C

0416e5821f47fd6f589c9ffff290241d 1256608900 settings|a:2:{s:14:“cart_languageC”;a:2:{s:5:"valu… C

96dec96c5ff491e279399ee895f6437e 1256613433 settings|a:2:{s:14:“cart_languageC”;a:2:{s:5:"valu… C

80c79710040804f8ed66ad46f797ed89 1256613667 settings|a:4:{s:14:“cart_languageC”;a:2:{s:5:"valu… C





Expanded:



83993c8a427af6ed20167bf8eb610806



_validator_data|a:2:{s:2:“ip”;s:14:“71.139.168.231”;s:2:“ua”;s:150:“Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) )”;}



0416e5821f47fd6f589c9ffff290241d



_validator_data|a:2:{s:2:“ip”;s:14:“71.139.168.231”;s:2:“ua”;s:103:“Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; SV1; .NET CLR 1.1.4322)”;}



96dec96c5ff491e279399ee895f6437e



_validator_data|a:2:{s:2:“ip”;s:14:“71.139.168.231”;s:2:“ua”;s:74:“Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)”;}



80c79710040804f8ed66ad46f797ed89



_validator_data|a:2:{s:2:“ip”;s:14:“71.139.168.231”;s:2:“ua”;s:74:“Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)”;}







WTH!!!



What is this cr@p AOL is pulling?



First they screw with the IP address. Now they screw with the User Agent?



How the hell does AOL users get different UA during the session?


  1. Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
  2. Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
  3. Mozilla/4.0 (compatible; MSIE 7.0; AOL 9.1; AOLBuild 4334.5006; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) )



    No wonder why AOL users can’t checkout.



    Because cs-cart validate both IP address and User Agent, AOL users keep getting a new session set in their cookie.



    New session ID ==> empty shopping cart.







    Okay, just f*cking set ‘SESS_VALIDATE_UA’ to false.





    define(‘SESS_VALIDATE_UA’, false); // link session ID with user-agent







    Damn it. Took me a whole week to troubleshoot the issue by looking at all the cscart code, logs, and sessions in the database table.

Okay. Issue still not fixed.



Decided to download AOL 9.5 and installed it on Windows XP. IE 6.0 is installed.



Privacy Settings set to “Medium”.





Tested:



amazon.com - works fine

buy.com - works fine

newegg.com - works fine

bestbuy.com - works fine

cscart 1.3.5 - works fine

demo.cs-cart.com - FAIL, shopping cart is empty during checkout

inkwow.com ( cs-cart 2.0.8 ) - FAIL, shopping cart is empty during checkout







Seems specific to AOL and cs-cart 2.0 only. It’s not the privacy settings since it works on other websites.

Okay. Here’s the fix.



TESTED FIXED. :smiley:





Added the following line to the ‘config.php’ file:



```php

define(‘SKIP_SESSION_VALIDATION’, true);

```



This will skip the IP address and Users Agent check. It works. Tested out already using AOL 9.5 on Windows XP.

















You know why it didn’t work earlier when changing:



define(‘SESS_VALIDATE_IP’, true); // link session ID with ip address



to:



define(‘SESS_VALIDATE_IP’, false); // link session ID with ip address





Because of the code below that’s part of ‘class.session.php’.





```php

static function get_validator_data()

{

$data = array();



if (defined(‘SESS_VALIDATE_IP’)) {

$ip = fn_get_ip();

$data[‘ip’] = $ip[‘host’];

}



if (defined(‘SESS_VALIDATE_UA’)) {

$data[‘ua’] = !empty($_SERVER[‘HTTP_USER_AGENT’]) ? $_SERVER[‘HTTP_USER_AGENT’] : ‘’;

}



return $data;

}



```





How could I have missed that? Must be tired.



The code below just checks to see if ‘SESS_VALIDATE_IP’ or ‘SESS_VALIDATE_UA’ is defined.



It doesn’t matter if you set it to ‘true’ or ‘false’. Either case, it’s defined.





DOH!



Guess you can commented this out:


define(‘SESS_VALIDATE_IP’, true); // link session ID with ip address


So it won't be defined.

SOLVED!



Welcome back to higher conversion rates!