Firefox loses shopping cart when cookies are enabled

[Randall]

I hope this isn't a wild goose chase, but it's driving me crazy. My testing is apparently being complicated by ShopSite reverting to shopping cart info it stores in various ways. To begin, can somebody tell me if they experience this, too? The site is http://www.legweardirect.com.

Here's the problem (all on a PC)...

Using ShopSite 7.1.4 Pro, with some browser/cookie setting combinations ShopSite is losing the shopping cart after the visitor views it, goes to a shopping page, then views the cart again without having added more to it. The cart can be restored by using the back button to get to the last view of it (then clicking refresh if necessary).

Firefox 3.0.5, **DOES** work if cookies are denied. But NOT if they are enabled.

IE6 does **NOT** work if cookies are denied, although results vary, possibly because ShopSite is defaulting to other references.

Chrome works (not sure how that's set), and Safari sometimes works but didn't at first (still trying to work out its pattern).

I realize if there's no cookie, ShopSite defaults to the query string, and then to the IP address. That's probably confusing IE, and I can live with that because most people wouldn't change settings in the middle of a visit. But Firefox is a problem. Before I go crazy trying to figure out every combination of browsers, settings and resettings, does anyone know what's happening with Firefox?

The ShopSite version is 7.1.4 Pro. FWIW, this version supposedly fixed what sounds like a similar problem, as noted in its "what's fixed" list (except my situation does not involve the checkout screen, and in Firefox, the failure occurs if cookies are **not** turned off):

>>If cookies were turned off in the shopper's browser, the value that stored the location they came from before entering the shopping cart would be lost if they went to the checkout screen then use the 'Return to Cart' function to return to the initial shopping cart screen, causing the 'Empty Cart' and 'Continue Shopping' functions to return the shopper to the main store page instead of the last page they had been on.<<

[Jim]

I noticed that when I placed an item in the cart and then went to the billing screen the url changed from http://www.legweardirect.com to
https://legweardirect.com
NOTE the missing www.
To a web browser these are two entirely different domains and cookies written by one domain can not be read by another domain. So if you have pages that refer to the shopping cart as www and others that reference it without the www that would end up with 2 different cookies one for the one with the www and another for the one without. This would also mean 2 different shopping carts.

My guess is that this is what you are seeing as the problem. So be consistant in the way you reference your site. It should either be with the www or without it as it is configure in your authorization file.

[Randall]

Interesting. I see that -- although the shopping cart page URL includes the www -- the product page's form action parameter does not. It's been years since I installed ShopSite; I don't recall if there was some reason for that. Regardless, I'm redfaced.

When I figure this out further, I'll post again...

[Randall]

Wait a minute. I was about to add the www. to a bunch of pages and test, but it occurs to me, if this matters, should the action URL parameter be absolute? What if somebody accesses the site without the www? (I see that trying that in Firefox does improve behavior, but the www creeps back in when shopping continues.)

I tried adding www to the URLs in Preferences > Hosting, but that just results in a browser message saying the SSL certificate is in the name of legweardirect.com, no www. Sigh.

Clearly I need to go over the instructions and audit everything. Meanwhile, although I had to revert the Preferences SSL specs to non-www, I tried taking the www out of the Merchant CGI and Shopping Cart CGI fields. Firefox started working when in cookie mode, but now IE6 hangs on the way to the cart or checkout... usually.

Comodo has supplied a revised cert that supports both the www and non-www versions of the https URL. Hopefully that, and maybe upgrading to the latest version of ShopSite (and then if necessary, adding www. to all the HTML a and form links) will do the trick.

But what about the store's "auth" file. Is that specific to whether www is used or not?

[robm]

The best/easiest thing to do is make sure *all* of your add to cart / view cart links on pages are absolute URLs that match the URL "Shopping Cart CGIs URL:" under Preferences -> Hosting Service.

This will force everyone to use the correct URL when adding things to the cart or viewing a cart. The SSL URL does not have to match when they go to checkout, and the page links themselves to pages in your site can be of any format. The key is making sure the add to cart / view cart links are absolute and go to the same URL as is set in ShopSite.

The auth files should match your cart URL to keep everything "in sync" so to speak, but it is not required.

[Randall]

Thanks, so much.

Verio has just informed me that their server does not support the dual-version SSL certificate, so, rather than change the certificate and the auth file, I'll make all shopping cart, checkout and Preferences links to absolute, non-www URLs.

Although, I'd prefer to keep everything even more in tune (with itself and most users' practice) by changing the cert and auth file to www, and hard-coding the links (and preferences) that way. Same effect, correct?

Rob, would a LexiConn server support the dual-version cert?

[robm]

As long as your webpages, add to cart / view cart links, and cart match URL wise (either www. or not), then everything should work fine (cart behavior, mini-cart etc...). It should be easy for your host to re-issue your auth if you want to keep everything under the www. prefix.

You can also put a mod_rewrite .htaccess rule in place to force whichever URL you decide on, which will keep everything uniform no matter what form of the URL a customers enters in on.

The checkout secure URL does not have to match your cart/pages URLs, so this can be whichever version you ordered from Comodo. If you ordered a wildcard SSL certificate, that should work fine.

Most hosts should be able to support a wildcard SSL certificate, as they operate the same as a regular SSL certificate.

[Randall]

I think I've got this resolved. FWIW, here's the summary.

• Made sure all forms leading to the cart do not include the www.
• In the cart template, made absolute all links leading back to other pages, including the www, and made image paths absolute while I was at it.
• Removed www from all specs available to me in the hosting Preferences.

This seems to have fixed things for everything except IE6. IE6 would work for the first product on a fresh visit, but then hang next time I tried to access the cart in any way. Progress bar went about 40% then nothing. I minimized everything on my desktop to see if there was a cookie prompt lurking, but saw none. Doesn't seem to have been a memory thing on my computer, either, because I get the same behavior on a notebook.

Solved the IE6 problem by going to Internet Options > Privacy and disallowing cookies for the domain (incidentally, in that process the www is irrelevant) which forces use of the query string, and it turns out that allowing all cookies for the site also avoids the hang. I'm guessing that when IE6 privacy is set to prompt, sometimes it waits but doesn't display the prompt. (I have also encountered this occasionally with other sites.) Whatever. If this turns out to be a problem beyond my own installation, I suppose I can add some help for IE6 users.

Oh, drat -- now IE6 works on the notebook, too. Well, that's okay with me.

Incidentally, this was buried in a Microsoft support document. For years I've been looking for a way other than parsing through the Temporary Internet Files folder...

http://support.microsoft.com/kb/283185/ :
> Existing cookies from sites that you decide to block will be deleted.

Only thing left is to get the cert un-wildcarded, because now it's producing scary warnings. Sigh.

Thanks to all!

[Randall]

The site seems to be working whether the visitor arrives with a www or not, but by the way, Rob, I tried using the .htaccess RewriteEngine code you posted at
http://support.shopsite.com/forums/viewtopic.php?t=2495&highlight=rewrite
but it doesn't seem to take.

I assume I would see results of the rewrite in the browser address line, right?

As I recall I tried using mod_rewrite to fix URLs resulting from old links and bookmarks to our SoftCart version, and it didn't work either. Maybe my various trials were buggy, but I checked the heck out of it and concluded that Verio Hosting 2000 doesn't support mod-rewrite even though they said they did. At the time, I was pretty shocked that they discontinued SoftCart plans without any support regarding URLs for SC customers migrating to ShopSite. But that's another matter and old news.

[robm]

The site seems to be working whether the visitor arrives with a www or not, but by the way, Rob, I tried using the .htaccess RewriteEngine code you posted at
http://support.shopsite.com/forums/viewtopic.php?t=2495&highlight=rewrite
but it doesn't seem to take.

I assume I would see results of the rewrite in the browser address line, right?

Yes, if mod_rewrite is supported, the URL should be re-written in the browser address line.

[Randall]

It works! Thanks. The site seems much cleaner with all the visits consistent. Not sure why it doesn't rewrite the shopping cart and checkout pages, but just as well.

Now I'm tempted to experiment again with rewriting incoming links from our old SoftCart days, but I'd better leave well enough alone.