6.14 to 6.15 problem with cookies

[electroh]

I have just upgraded from Catalog 6.14 to 6.15.
I am now having problems with the cgi script sometimes returning a 404 error, which can only be resolved by deleting the cookie in the machine trying to access the site.
After removing the cookie, the site runs normally.
Has anyone come across this problem before.
Thanks
Richard

[Nadeem]

Hi Richard

I have not heard of this issue, what your website url for us to test it on? Is it a intermittement issue?

Kind Regards

[electroh]

Thanks for replying, the web site is www.electrohill.co.uk.
It does seem to be an intermittant problem, but once locked out of the site, the only way to get back in is to delete the cookie.

[electroh]

Hi Nadeem,

The problem occured again today. This time I deleted my session file from the web server, which also cleared the fault. So there must be some intereaction between the cookie and the session file which makes a simple search (/cgi-bin/ss000001.pl?SECTIONID=xx) give a 404 error.

Richard

[Mike Hughes]

Corrupt session files do sometimes give problems with the scripts. The cookie links to the session file so deleting it removes the link to the corrupt session file and everything is hunkey dorey again.

I've had problems in the past when debugging other bits of the website in subdirectories. Are you doing anything along these lines? i.e. have you other bits of your website in wwwdotyourwebsite.com/somesubdirectoryname/...

Mike

[electroh]

Mike,

There are no subdirectories below acatalog. I think the problem might come from having 2 concurrent session files.
I first went into the site normally through the home page. A little later I accessed the site through a Google link straight to a product page, this is when the second session file was created, and the 404 error occured.
Is there a work around to stop this from happening?

Richard

[scottish]

Richard: I wonder if you are experiencing the same problems that have been hitting my sites, i.e. you can't access the sites after linking directly to a catalog page after a Google search.

If you have access to the Developers form, do a search on 'Google Problem' and you will see the string of messages - a work around has been suggested, but no-one has agreed that this is an Actinic or Google problem.

If you don't have access to the Developers forum, call me on 01224 626699.

Bernie

[dave_finlayson]

If there is a solution could it not be available to the whole community. I suspect this is causing more problems than have been noticed!

Dave

[scottish]

Dave: here is an edited string of messages from the Developers forum. I agree with you that this may be a problem that other preople are experiencing - maybe without knowing it.

Initial Message:

I posted a message on the V6 forum, so far without resolution. Can any of you guys help me?

We had had a number of reports of people failing to access the catalog on one of our sites after a search on Google. I have replicated the problem on different PCs and I have also seen it occur on a site unrelated to us.

Do a Google search on Eric Auld and then click the main link and then the second one in the Google results list. (I know that this is the 'mid point' when catalog checks to see if there are log-on accounts). Using the main site link, the site appears, but clicking Online Shop takes you back to Google. The second link results in you staying within Google.

Have you come across this problem - more importantly any thoughts on resolution?


Ist Reply:

create a robots.txt file in the root of your public web files area that excludes google from indexing the cgi-bin method of getting into the site..

Further to your problem. It would appear that if someone clicks on the link (cgi-bin) one, then some cookie from google is loaded into the users browser and then even if they click on a normal (non cgi-bin link) it keeps bouncing back into Google!

Strange, but true, so exclude robots from the cgi-bin should do it, but make sure that you have methods for the bots to get into your site from the home-page without going via a cgi-bin script...


2nd Reply:

The solution is not to block google or any search engine from the site, but from the cgi-bin, which is where the problem occurs.

The link that comes up for your site search is:
http://www.google.co.uk/search?hl=e...le+Search&meta=

Look at the link that it shows and you will see that Google themselves add in a space between the . and the pl as it appears in the text, but the link itself when you hover your mouse over it is complete as it should be.

Upon clicking the link, Google loads a cookie into your machine which then bounces you back to the Google search results you have just clicked within.

Apart from preventing search engines from indexing the cgi-bin, I can not see how the Actinic software can implement something to overcome how Google is operating its own search results??

Any takers on that one

(Several other messages)

Further Message:

We had previously refreshed the site and cleared all cookies and the site access worked OK. But as soon as the route to the site was made from the Google listing (the second displayed link - the one with the intermediate step which checks for Log-in accounts) Actinic is placing the cookie related to Google and from there on you can't access the shop.

My technical associates can't understand what's happening, except to say that it appears not to be server related but is related to the Perl scripts that are manipulating the cookies.


Further Message:

Sorry to come back again on this, but yet another site is experiencing the problem of the user being thrown back to Google after starting the search there.

This site is Countryside Prints - a Google search lists it on the first page. As before, the link is the mid-point check that Actinic makes before redirecting to the catalog pages.

Frustratingly, this does not happen on all PCs, but we keep getting customer calls that quote the Google interference. Obviously, for every person that calls, there will be many others that don't.

Can anyone help?

Reply:

The only sure fire way of ensuring that potential customers can get to you via google is to use the robots file to block the googlebots from the cgi-bin, that way Google will not index it or any of the script connections and then the normal links will continue to be indexed and included in the google search results.

All of that said above, you have to ensure that you provide some (non cgi-bin) method of getting into your site for the bots to follow, i.e. text links maybe at the base of the page and outside of all tables etc, which is simply put 'there for the bots to follow' thus ensuring that the blocking call in the robots file does not affect you more than the problem with the google including the cgilink in the first place.

We know of a lot of customers who have done this, without hassle at the end of the day and from what we can tell, it is not a Developer version problem...


Further Message:

thank you for your patience. We have used the robots.txt file and will add the text based link as you suggest.

On the question of whether this is an Actinic problem, (apart from the real culprit being Google's cookie) maybe this is an issue for Business rather the Developer, because the offending reference that Google is indexing is that one that checks to see if there are log-on accounts? If there was a setting that bypassed the account check on sites created from Developer, would this solve the problem?

Without wishing to extend that debate too far, it also remains a mystery why some PCs do not experience this rerouting problem even when the search started at Google.

Reply:

Yes, the nologin= is the bit which is sending the robots through the cgi-bin route, but on why some get it and others do not, we have found that those who have spyware checkers on there systems which have inoculated the systems, and those who set cookies to always blocked or have assigned to block googles cookier, does not get this problem. Strange, but what we have come across..

(End)

Please let me know if this fits your situation.

Best wishes.

Bernie

[electroh]

Unfortunately I don't have access to the developers forum.
I have excluded robots from cgi-bin, *.cat, *.err, *.fil (Do a search on Google for nqset00.fil and you'll see why).
I don't think it is Googles cookie which is causing the problem, but the Actinic cookie generated when accessed through Google. As far as I can see Actinic also generates a new session file, so you end up with 2 session files and one actinic cookie which possibly throws a wobbly with the cgi script.
Deleting either of the session files or the cookie will clear the problem.
Richard

[Nadeem]

Hi Richard

For this issue, i would suggest in your contact Actinic Support. If you have cover then phone: 0845 129 4848, otherwise post an email ticket on: http://www.actinic.co.uk/support/register.htm

Kind Regards

[scottish]

Richard: further to Nadeem's last post, if you get an answer from Actinic Support, can you share it with the forum. This problem (I am still unceratin whether your problem is that same one that I have been chasing) has undoubtedly been losing customers and I would love to hear a good solution.

My problem stams from the fact that Actinic checks whether there are customer accounts (i.e. Business edition) before opening the catalog. If there are no customer accounts, couldn't the link code be changed to take you straight to the shop?

[electroh]

Bernie,

I will keep you updated on any progress with Actinic Support. Although we don't use customer accounts, our menu system is dynamically built using javascript, and uses the ss000001.pl script. This evening I am going to check whether this problem occurs only with Google, or with other referal agents like Kelkoo as well.

Richard

[electroh]

It seems that Google is modifying the session file and changing the BASEURL to www.google.co.uk


<SessionFile Version="1&#46;0">
<URLInfo>
<LASTPAGE>http&#58;&#47;&#47;www&#46;electrohill&#46;co&#46;uk&#47;acatalog&#47;specialoffers&#46;html</LASTPAGE>
<LASTSHOPPAGE>http&#58;&#47;&#47;www&#46;electrohill&#46;co&#46;uk&#47;acatalog&#47;specialoffers&#46;html</LASTSHOPPAGE>
<BASEURL>http&#58;&#47;&#47;www&#46;google&#46;co&#46;uk&#47;acatalog&#47;</BASEURL>
</URLInfo>
<CheckoutInfo>
<BillContact/>
<ShipContact/>
<ShipInfo/>
<TaxInfo/>
<GeneralInfo/>
<PaymentInfo/>
<LocationInfo/>
</CheckoutInfo>
<ShoppingCart/>
<Payment/>
<IPCheck/>
</SessionFile>

After that nothing works

Richard

[scottish]

The other frustrating thing is that the problem does not appear to occur on all PCs - searches on your site work originating at Google fine for me.

Your analysis of the base URL explains why, once the problem occurs, searches from other sites, Alltheweb etc, all return to Google.

I did send a query to Google and chased for an answer, but they did not respond.

Hopefully someone will start to pick this up as a serious issue.

Bernie