Cookie Problems!

rdevarona · Post by **rdevarona** » Wed Feb 20, 2008 1:27 pm

Hi guys,

Does anybody know where and on what page AC sets the session cookies? I've got an issue that's costing us $$. It seems that one can't get directly to any of the product pages on our site without having first visited our home page. Mike from AC helped me narrow down the issue to a cookie problem. Try this on your install and let me know what happens.

1. Copy the url for a product detail page to your clipboard.
2. Clear your browser cookies.
3. Paste the url into your address bar and try to navigate directly to the product description page.

At this point, I get an unhandled exception error. If I go to my homepage, it will load just fine. I then paste the product url back into the address bar and the page renders perfectly with no exceptions.

I'm trying to figure out if this is due to something that I did in our site, or if it happens on a standard install. I can't think of anything that would affect how AC is storing cookies on our site visitors' browsers.

Any help would be greatly appreciated.

Regards,

rdv

jmestep · Post by **jmestep** » Wed Feb 20, 2008 3:01 pm

I just tried it on Joe's site (http://www.solunar.com) in IE and didn't have a problem.

Post by **Shopping Cart Admin** » Wed Feb 20, 2008 5:48 pm

Hello,

So far we've been unable to reproduce this issue on our installations of AbleCommerce and it's not been reported by anyone else.

Intelliflex · Post by **Intelliflex** » Thu Feb 21, 2008 10:07 am

rdv

I have also tried to duplicate the issue and am not able to. Must be your install.

Post your findings as you debug, as we ARE a Community and we want to help when we can.

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 1:00 pm

I did a lot of debug over night and found that none of my category or product pages were setting the cookies that the home page sets. This seemed very strange to me since I haven't made any changes to the global.asax file where these cookies are set.

Working with my host, we changed the setting of Cookieless mode under the State Management section of ASP.NET to AutoDetect. This seems to fix the cookie issue, but now the Dataport Utility doesn't work.

Can anybody check what their current settings are for State Management to see if I've got something configured wrong in there?

Regards,

rdv

Intelliflex · Post by **Intelliflex** » Thu Feb 21, 2008 1:04 pm

rdv

If this is nothing more than a link to a URL, this should not have anything to do with a cookie.

Can we get to the site?

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 1:32 pm

Dave,

There are components on these pages that require session variables in order to track. My guess is that if these cookies aren't set right, those components (cart, wishlist, etc) throw exceptions. That's what was happening to us. I was able to see that the product and category pages (when linked directly) were not setting any cookies.

The site is accessible. You can first check: http://www.electricalmarketplace.com/6- ... 05C32.aspx

If that doesn't work, go to the home page (http://www.electricalmarketplace.com) then back to that link.

The first time that I thought something was fishy was while reviewing Google Webmaster Tools reports of our sitemap. Google claimed that more than 800 urls where resolving to 500 Internal Server Errors. My guess is that this was due to the same issue.

Regards,

rdv

Intelliflex · Post by **Intelliflex** » Thu Feb 21, 2008 1:51 pm

I went to the link and it worked fine.

Entry point in a site should be able to be from any page, creating the required session vars from there.

If this were to be an issue, this could have significant reprocussions with the Search Engines, since they normally direct a user to a product page, not the home page.

But again, I am unable to reproduce this issue, on our sites or electricalmarketplace.com.

sweeperq · Post by **sweeperq** » Thu Feb 21, 2008 3:32 pm

Same here, no error when visiting the page. What OS and browser are you using?

jmestep · Post by **jmestep** » Thu Feb 21, 2008 4:01 pm

No error for me also. (That's a nice site, though)

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 6:06 pm

rdevarona wrote:...we changed the setting of Cookieless mode under the State Management section of ASP.NET to AutoDetect. This seems to fix the cookie issue, but now the Dataport Utility doesn't work.

Yep, I would hope that you didn't see the issue. The changes I mentioned above fixed the exception problem.

@sweeperq, I was able to confirm the issue (when it still existed) on both IE and FF.

@jmestep, thanks!

rdv

Post by **Shopping Cart Admin** » Thu Feb 21, 2008 6:15 pm

Hello,

I don't believe I've ever seen that URL param (cookie auto-detect) running on any other website, so it might be masking the issue but it's not a long term solution.

I'm guessing that based on the error message a likely solution can be found. Testing the fix is going to be more difficult since we've still yet to reproduce this.

Intelliflex · Post by **Intelliflex** » Thu Feb 21, 2008 6:41 pm

I wonder if it might be an issue when a user goes to the site and they have cookies turned off in their browser.

You could set your browser to not accept cookies and switch back the setting in AC7, then turn cookies on and try it again, and see what happens each way.

Jus a thought!

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 6:44 pm

Mike,

That's exactly what I'm worried about. I'll tell you this, I'm certain that product and category pages were not setting cookies prior to the "Cookieless" setting change. I looked through all the code that's accessible to us as admins and found that AC sets its cookies via the global.asax Application_BeginRequest routine. This routine should fire every time a request is received by the server, regardless of what page is being requested. I can't understand why this wouldn't run when I visit either a product or category page directly. I figured either this was causing the problem, or there's some sort of IIS config issue.

I don't think that I should have to AutoDetect cookie support in IIS. I think there's something else that's wrong somewhere and by AutoDetecting cookis, I'm covering up the real issue. For now, though, it gets us working. Without this fix in place, all ad campaigns that land on category or product pages are resulting in errors if the user has never visited our site. This, for us, is a huge problem.

Regards,

rdv

AbleMods · Post by **AbleMods** » Thu Feb 21, 2008 7:26 pm

Global session state configuration values are overriden by the local site web.config file.

Ensure your web.config file contains this line:

Code: Select all

<sessionState mode="InProc" timeout="90"/>

The timeout can be whatever you want, but most importantly that it's set to "InProc" and there is no "Cookieless" parameter.

My guess is that is where you will find the problem.

It is possible for IIS to override this setting through a global web.config file, but for this to be possible, it must also be set to disallow local web.config. Incredibly unlikely in a share hosting environment and the fact all other aspects of your web.config function correctly. But it is possible - control is so strong that an IIS Administrator can override certain local web.config parameters but not others. It can get rather ugly in a poorly (or overly) configured environment.

If all else fails, just have the provider build a new IIS site and point it to your old folder. Make sure they don't change anything but the .Net version to 2.0 and add the default start page default.aspx. That'll give you a pretty good idea whether it's the IIS site setup or your local site config files.

My IIS server ASP.Net Configuration Settings shows state mode set to InProc and Cookieless mode as UseCookies. This is because it's pulling that information from the web.config file. I own my own server, so I have full console access and can compare any other settings you'd like.

Global.asax only provides the conduit for how the URL will be treated, it does not directly affect the cookie generation process so far as I understand it. My thinking on that may be wrong, but I thought that's how it worked.

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 7:43 pm

Joe,

Thanks for the details. Our SessionState line in web.config looks like this:

Code: Select all

sessionState cookieless="AutoDetect" cookieName="AC7.SESSIONID" timeout="90"

Changing this to what you have causes the exceptions to be thrown. I've got Session state mode = InProc in the GUI. Changing the cookieless parameter to UseCookies causes the exceptions to occur.

We're running AC on a dedicated box, so the "poorly configured environment" is totally plausible

rdv

AbleMods · Post by **AbleMods** » Thu Feb 21, 2008 8:25 pm

I've got Session state mode = InProc in the GUI

What GUI?

When you edit your IIS site settings in IIS admin, there are two configuration buttons. One is global and applies to all sites. The other is specific to that particular site.

The GUI button for your specific site settings should always match what the web.config file states. If it doesn't, there's a bigger problem. Most likely means the IIS site is pulling the wrong web.config file.

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 9:26 pm

Joe,

By GUI, I'm referring to IIS > [web site] > properties > ASP.NET > Edit Configuration > State Management. Not the global one.

The GUI is indeed changing the right file. I can verify by editing web.config and opening the GUI or by editing the GUI and opening the web.config. Whatever values I plug into one show up in the other. For some reason, mode="InProc" is displayed in the GUI, but not in web.config. I manually add it into web.config but the next time that the GUI modifies the file, it removes it. I think that may be the default value anyway, so it may not need to be explicitly stated.

Regardless of those settings, whenever I change cookieless to UseCookies, the exceptions start up again if I visit a product or category page directly.

rdv

Intelliflex · Post by **Intelliflex** » Thu Feb 21, 2008 9:35 pm

rdv

Does it only happen on "catagory' pages or "product" pages also? Does it happen on other pages, such as your contact page?

rdevarona · Post by **rdevarona** » Thu Feb 21, 2008 10:02 pm

Dave,

The issue only happens on category and product pages. I've got several pages that were created as webpage entries in the catalog, and those pages seem to show up just fine. All other aspx pages also work fine.

Regards,

rdv

AbleMods · Post by **AbleMods** » Thu Feb 21, 2008 10:07 pm

Man that sounds like a permissions problem.

Intelliflex · Post by **Intelliflex** » Thu Feb 21, 2008 10:09 pm

rdv

What error does the server throw? If you use the browser on the server, it should give you detailed information that is not shown to browsers on other machines. If you could, copy that and forward, this might give a clue to what it's complaining about.

Don't forget to reset the config file and clear the cookies to generate the error, then reset the config file back when you are done. You should be able to do this in a couple of minutes, also, you might do it late at night or early in the morning to minimize the chance of users being on.

rdevarona · Post by **rdevarona** » Fri Feb 29, 2008 6:35 am

I'm still at a loss with this one, but I thought I would give you guys an update.

I've installed AC on another one of our domains in demo mode
(http://www.decoratorfans.com) and it is not having the same issues. I've compared every single file in the new installation with the equivalent one in the http://www.electricalmarketplace.com installation. Of the files that would matter, the only one that shows a difference is web.config, and the only difference is in the SessionState parameter. If I replace the sessionState section from decoratorfans into electricalmarketplace, I get the same issue again in electricalmarketplace.com. In my mind, this is leading to some sort of IIS config issue, but I don't know how to prove it. This is truly baffling me.

Regards,

rdv

Post by **Shopping Cart Admin** » Fri Feb 29, 2008 6:48 am

Hello,

We never were able to establish the method to obtain this error. However in reviewing the code and the error message together they have written a possible solution to the issue. I'll get a copy of the patch to you today for you to test and let us know what you find.

rdevarona · Post by **rdevarona** » Fri Feb 29, 2008 7:49 am

It worked!

rdv