Validated OS ID - Professional Response

[Guest]

Good day everyone.

 

What is the story with the OSID? I would like to get rid of it as I hear this is no good for SEO and spidering. But theories conflict. For those of you who have mastered or written for OS Com, can you please tell us what the right thing to do is for OSid.

 

If we should remove them, what is the approved method for doing so?

 

Thank you

[stevel]

With a properly configured store, the osCsid in the URL will go away after the second page. If it does not, then either your configure.php is wrong or the user's browser is not accepting cookies.

 

As far as search engines go, you want to make sure that they never get a session and therefore never see the osCsid. The way to do that is to turn on "Prevent Spider Sessions" in admin under Sessions and keep catalog/includes/spiders.txt up to date. I maintain this as a contribution.

 

It is also helpful to keep spiders away from links you don't want them to follow. Use of robots.txt will help with this somewhat, but you can also add code that tests $session_started and display links such as "Buy Now" or the product list sorting links only if that variable is true.

[Guest]

"With a properly configured store, the osCsid in the URL will go away after the second page. If it does not, then either your configure.php is wrong or the user's browser is not accepting cookies."

 

This is what I am talking about. Someone who know what he is talking about... Thank you

 

Now can you eplain further on this. What should our settings be and where to ensure the osCsid is working properly

[stevel]

The key is very simple. There are two sets of defines in catalog/includes/configure.php:

 

HTTP_SERVER

HTTP_COOKIE_DOMAIN

HTTP_COOKIE_PATH

and

HTTPS_SERVER

HTTPS_COOKIE_DOMAIN

HTTPS_COOKIE_PATH

 

In each set, the _COOKIE_DOMAIN define should have a value that is the domain and only the domain from the corresponding _SERVER define. So if for example you have:

define('HTTP_SERVER','http://www.example.com');

the corresponding COOKIE_DOMAIN define would be:

define('HTTP_COOKIE_DOMAIN','example.com');

 

HTTPS_COOKIE_DOMAIN must similarly match the domain of HTTPS_SERVER.

 

The _COOKIE_PATH values should match the corresponding DIR_WS_xxx_CATALOG defines.

 

When you first visit an osC store, all of the links on the initial page will have the osCsid in them. As soon as you load any of those pages, and if your browser accepts the cookie, then the osCsid will disappear from links from then on in that session. If the user's browser does not accept the cookie, then the osCsid will remain, as it must, otherwise the session cannot be maintained. If your store behaves this way, then you have it set properly.

 

When non-human (spider) visitors come to your store, you don't want them to have a session. This will still allow them to see all of your store, but they won't be able to add items to a cart. To prevent spiders from getting a session, you have to turn on Prevent Spider Sessions in admin. This causes the browser identification (user agent) string to be matched against a set of strings in includes/spiders.txt. The user agent is downcased and each line of spiders.txt is a string looked for in the user agent. For example, Google's spider has a user agent (usually) of 'Googlebot/1.0' or something like that. One of the lines in the standard spiders .txt is 'googlebot', which matches. In my updated and streamlined spiders.txt, the string 'ebot' matches Googlebot. If a match is found, no session is started and $session_started is left false (it is set to true if a session is started.) You can test on $session_started to control what text or links are presented to a spider.

 

To test this, you want to clear any store cookies you have in your browser and set the user agent to something that looks like a spider, say "Googlebot". Then visit the store and see that there are NO osCsid values in links and you can't do anything, such as add to cart or login, that requires a session. If you do, you're brought to a 'cookie_usage' page. Ideally, you will have taken steps to prevent spiders from trying to do such things.

[Guest]

 

 

Stevel

 

Thank you for your assistance and answering my questions so well.

Suppose for a moment all the settings you mentioned above are correct, yet the user goes from one page to the next with the osid's. And Cookies are enabled. (This is me doing the testing).

 

What next? The oscid is still showing.

 

Another issue.

 

Here are my session settings in the configuration

 

Force Cookie Use False

Check SSL Session ID True

Check User Agent True

Check IP Address True

Prevent Spider Sessions True

Recreate Session False

 

Now if I go to force Cookie use to True, my navigation products links on the left column changes font colors and the style sheet seems to skew.

 

Thank you for you feed back.

[stevel]

My advice is to leave all the "Check" items false, as they will block legitimate visitors. I also don't like Force Cookie Use as it will keep away some buyers (and it can't be used if your host uses shared SSL.) I have no idea why changing any of these would cause the page appearance to change.

 

If you give me the URL of your store, I can see if anything looks amiss.