Although I normally would ignore AOL users, my project has a large number of AOL users for some reason.
They are reporting that they are unable to navigate throughout the website and that all links redirect to the home page.
I was able find a copy of AOL on a website that archives old versions of browsers and I can replicate the issues in AOL. All other browsers are working fine.
I’ve done some digging and all I can find is that AOL is using the users native IE install, so the browser compatibility should not be the issue. I’ve also uncovered that AOL routes all traffic through a proxy server which caches all pages and images. I have a feeling that this is what is causing my problems, but have no idea what I can do to fix it.
My project is located at <a href="http://www.franksgreatoutdoors.com">www.franksgreatoutdoors.com</a>.
Although I normally would ignore AOL users, my project has a large number of AOL users for some reason.
They are reporting that they are unable to navigate throughout the website and that all links redirect to the home page.
I was able find a copy of AOL on a website that archives old versions of browsers and I can replicate the issues in AOL. All other browsers are working fine.
I’ve done some digging and all I can find is that AOL is using the users native IE install, so the browser compatibility should not be the issue. I’ve also uncovered that AOL routes all traffic through a proxy server which caches all pages and images. I have a feeling that this is what is causing my problems, but have no idea what I can do to fix it.
My project is located at <a href="http://www.franksgreatoutdoors.com">www.franksgreatoutdoors.com</a>.
Any Clues?
I don’t have any ideas on how to fix, but curious why you would normally ignore AOL users. Isn’t it the purpose of a e-commerce website to gather sales from all users. I know AOL, is no longer the big boy on the block as when they first started, but still have a tremendous user base that can not be ignored.
I also have the same problem with Singtel users. In the end, I have to use version 1.1.6 instead. I am aware that version 1.1.7 and 1.1.8 have lots of bugs fixes, and sooner or later, I have to solve this problem.
One tip, tell AOL customer to setup proxy in their browser to access your website. That method works for Singtel users.
This is a very difficult problem for programmers, since this problem lies in ISP, not in code. People from IT infra or support may know this issue better.
I ran into this exact issue with a client and after signing up for an AOL 9.1 trial and much debugging, I managed to figure out that the issue is being caused during session validation. It seems as though AOL actually sends requests from different REMOTE_ADDR addresses (probably proxies and such) which causes Magento to reset the session if session validation is too strict. To fix the issue, I changed the following:
Go to Magento’s backend and then to System/configuration/web/session validation settings. Set Validate REMOTE_ADDR to NO.
I ran into this exact issue with a client and after signing up for an AOL 9.1 trial and much debugging, I managed to figure out that the issue is being caused during session validation. It seems as though AOL actually sends requests from different REMOTE_ADDR addresses (probably proxies and such) which causes Magento to reset the session if session validation is too strict. To fix the issue, I changed the following:
Go to Magento’s backend and then to System/configuration/web/session validation settings. Set Validate REMOTE_ADDR to NO.
worked great!!! I had similar problem, not with AOL, but squid proxy server on local network…
Go to Magento’s backend and then to System/configuration/web/session validation settings. Set Validate REMOTE_ADDR to NO. Fixed the problem
thanks for that!!!
I ran into this exact issue with a client and after signing up for an AOL 9.1 trial and much debugging, I managed to figure out that the issue is being caused during session validation. It seems as though AOL actually sends requests from different REMOTE_ADDR addresses (probably proxies and such) which causes Magento to reset the session if session validation is too strict. To fix the issue, I changed the following:
Go to Magento’s backend and then to System/configuration/web/session validation settings. Set Validate REMOTE_ADDR to NO.
After testing and making sure everything works in IE6, 7 FF2, 3, Opera etc. I also went to live and got AOL users on my back.
As you can see here http://webmaster.info.aol.com/detection.html AOL 9, the latest, is still IE6. that’s crap but IE6 alone works fine. AOL’s IE6 implementation doesn’t.
I’ve now made the REMOTE_ADDR validation change and fingers crossed, that sorts it.
Hey J.T.
I’m running a similar setup as you are and I had made the REMOTE config change. I too was only able to test in I.E. 6 and not true AOL but since then I’ve had orders from AOL’ers so I think that we’re OK.
Thanks for posting this solution. A customer walked into my client’s store today to complain that he couldn’t access the website using AOL’s browser. I’ve made the config changes detailed here and asked the customer to let me know if it works for him.
I too have a client that runs AOL, and they aren’t too happy being unable to browse their own site… I tried to get them to run Firefox, but they don’t want to..
I did the Fix above ( SESSION VALIDATION / VALIDATE REMOTE_ADDR ---> “NO” )
but they still claim to not be able to use the site.
Does anyone have any further insight into this?
I’m running Magento 1.2.0.3
(Is this AOL thing fixed in the latest ver.? If not, please don’t simply tell me to update in “hopes” that it will work.. I know.. I should update anyway)
What about those other settings in “Session Validation” like
Validate HTTP_VIA
Validate HTTP_X_FORWARDED_FOR
Validate HTTP_USER_AGEN
What do those do? can I select “no” to those too without shutting any major features off?
I changed all the Session Validation settings to NO. Since I did this I have not had any reports of problems with AOL users and these changes do not appear to have affected anything else.
If you switch them all off, you potentially risk sessions being able to be hijacked, that’s the only thing. You don’t loose functionality.
There are earlier posts where Magento support recommended switching all off except ‘Validate HTTP_USER_AGENT’. Do you think that doing this also leaves a site open to hijacking
As a confirmation, my client says her AOL browser now displays the site correctly with the following settings in the admin
system / configuration / general / web / session validation settings
Can anyone shed some light on this? Can someone clarify and define this possible “hijacking” as mentioned above.
I’m glad I got the site to “work”.... grrr.... for my client, but how responsible is it to go switching things off and on that can affect site security??!?
AOL proxies everything. An AOL user browsing your site may hit the homepage from IP 123 and the category page from IP 234. The product page can be requested from IP 345.
With REMOTE ADDR and FORWARDED FOR enabled, Magento sees that this one user switches IP, therefore assuming it’s being hijacked so it’s preventing certain session based functionality, hence checkout etc. failing. Switched off, Magento will stop checking the IP matches and let them through. AOL users are happy, other users are not affected.
But now, especially on shared hosting environments, you have a possibility of hackers hijacking sessions and being able to ride on the visitor’s sessions, being logged in etc. No big deal really, unless you sell sex toys or other sensitive stuff, or display card details.
So ideally, as AOL is MSIE based, we should be able to conditionally turn this validation off instead of a blanket disabling.
