The Dreaded Aol Issue, can't add items to cart in AOL browser Options

[stevrons]

I see this has been discussed but with no real solution. The issue is that customers using AOL cannot add items to their cart because the AOL browser functions differently than all others. I know the "solution" provided by Avactis support is to comment out some code and in effect lessen the security of our checkout pages, but I find that to be an unacceptable solution. And yes AOL is not used by a huge percentage of users, but it's used by enough where we've gotten multiple complaints from customers trying to place orders and can't. Has someone come up with a real solution to fix this issue that does not involve decreasing the security of the checkout pages of the site?


Thanks

[DonH]

Actually the solution is much simpler and doesn't compromise security. The problem is that AOL uses a different server for HTTPS connections than for regular HTTP. The issues happened when the visitor would go from regular HTTP to HTTPS for cart functions. The solution was to simply enable HTTPS for the entire storefront. Unless the site is on an overcrowded server, the additional overhead is insignificant. In fact, our AOL users reported what they felt was a speed increase. Other users report no change.

[stevrons]

Actually the solution is much simpler and doesn't compromise security. The problem is that AOL uses a different server for HTTPS connections than for regular HTTP. The issues happened when the visitor would go from regular HTTP to HTTPS for cart functions. The solution was to simply enable HTTPS for the entire storefront. Unless the site is on an overcrowded server, the additional overhead is insignificant. In fact, our AOL users reported what they felt was a speed increase. Other users report no change.

That's not a real solution. I'd call that a hack, or a work around, no one should have to secure the entire storefront to get aol user's to be able to buy products. For one, that solution will not play out the same for all, all sites will not load quickly once shopping pages are secured. And regardless, it's just not a true solution, the Avactis software needs to be updated so that people can add products to their cart using any browser and their storefront should not have to be SSL secured. I never see storefronts that are completely SSL, there's a reason for it, it's unnecessary and it is indeed a burden on resources.

[DonH]

The "real" solution is for AOL to not change to a server with a different IP address when users use an HTTPS connection. The issue is not present if a user does not use the AOL branded browser and instead uses regular IE or Firefox, even when using AOL as their ISP. It only happens with their branded browser.

So, no matter what you do, it's a workaround. It's far less secure to allow the change of IP addresses when the visitor goes to checkout. How do you distiguish that from a keylogger or such rerouting the data stream? You could ban the AOL browser, but that doesn't seem like a good idea.

In the "old" days of the web, server hardware and software was not what it is today and SSL was a burden on available resources. Today, if you have taken care to optimize your graphics, the performance hit on a server optimized for mysql applications is pretty minor.

I spent time with tech support researching the issue. I put up test pages that captured a bunch of data and recruited several AOL users to visit those pages in a specific order using the AOL browser and again using either IE or Firefox. The logs clearly showed the change in IP address when the AOL browser went from the http page to the identical page with an https prefix.

After that, I experimented and decided that placing the entire front end under https had no detectable slowdown and I could still accomodate AOL users.

I have never, ever seen any other ISP change IP address when a user moves to an encoded page on the same website. As you said, there is a reason for it. So, you can try to convince AOL to change, or come up with a way to accomodate that IP address change without compromising the security that a customer expects from SSL, or you can find your own workaround.

Until then, please keep your insults to yourself. I don't appreciate them. It's downright rude to insult someone trying to help.