I am calling this post “osCommerce Session ID Nightmare” but the same exact problems occur on other stores as well, which I consider osCommerce derivatives such as CRELoaded, osCMax, Zencart, CubeCart, Xcart etc.
So keep in mind that the information provided in this blog post is not exclusive to osCommerce store owners, but applies to most shopping carts which append a Session ID to the URL.
Here it goes …
A lot of osCommerce store owners are not aware that indexed session IDs can lead to tremendous privacy violations and store nightmares. Below, I will try to clarify the seriousness of this problem.
Let’s say you operate a store but decide to leave the session IDs active for search engine spiders.
The Crawl and Indexing process:
This is what will happen:
Googlebot, Slurp (Yahoo’s robot), MSNbot etc. will eventually visit your store. By default, your store does not have the ability to recognize if these visitors are search engine bots or regular visitors.
Therefore, your store will treat these spiders as regular visitors and assign each spider a unique session ID immediately upon visit.
“For the website to be able to track the client, a session ID is uniquely created and stored as a cookie on the clients computer.
This allows the website to track the client via the uniquely created session ID and to know if the client is in an authenticated state with the web application or not.”
(Ref: osCommerce Knowledbe Base: Security and Privacy Proposal)
blablabla … in simply words, one of the main purposes of the session ID is to ensure that products which were added to the shopping cart, remain within the cart, even if the customer navigates away from the shopping cart page, the site or closes the browser window and visits the site at a later point.
While the search engine bots crawl your site, this unique session ID will be carried throughout the crawl process and appended to every single Category URL, Product URL, Information page URL and other URLs found within your store.
While most search engine spiders are quite sophisticated, they can be a bit dumb at times, and do not recognize the osCommerce session ID as an appended string and consider it part of the whole URL. While reporting the URLs back to the corresponding search engines’ datacenters, the session IDs are kept as a result.
Eventually, you end up with a series of indexed store pages, and you’ll notice that most of these URLs have session IDs appended to the default store URLs.
Go to Google, Yahoo or MSN and run a “SITE:” command to see if that’s the case with your store! (SITE:www.sitename.com)
Say Hello to Freddy:
Now here is where the real problem begins…
Let’s say a visitor reaches your store by following one of these indexed pages which has the session ID appended to the URL. Let’s call this Visitor A.
The osCommerce system recognizes Visitor A as a unique user and does not feel the need to create a new session ID.
Next, Visitor B reaches your store. Visitor B also clicked one of your indexed pages within the search engine result pages. (SERPs)
Due to the fact that Visitor B entered your store using the same exact session ID as Visitor A, the osCommerce system actually thinks that Visitor B is the same user as Visitor A. Although both visitors have different IP addresses and might be at completely different locations, using different browsers, it doesn’t matter to the osCommerce system. The only thing that matters to osCommerce is the unique session ID, which identifies a unique user, but in this case Visitor A and Visitor B are considered strictly the same user as the session ID is 100% identical.
If both A and B are browsing your store simultaneously using the same exact session ID, this is where the nightmare begins:
- Visitor B might add an item to his/her cart which online prescription drugs without a prescription will appear within Visitor A’s cart.
- Visitor A might delete items from his/her cart which will also be deleted from Visitor B’s cart.
Try to imagine this situation with Visitor’s C, D, E etc. all using the same session ID while browsing your store simultaneously, but interested in different products, or different product attributes for that matter.
These users will abandon your store thinking that there is something wrong with your cart, which isn’t even the major problem.
Freddy vs. Jason:
You may ask yourself, what could be worse than this. Here is the deal:
Imagine Visitor A and Visitor B are logged in customers of your site. As I explained above, osCommerce looks at the session ID to differentiate users. If both IDs are the same, A and B are considered the same person. What do you think happens when A navigates to the address book and updates the address? What do you think happens to B’s address details? Exactly! They get overwritten with A’s details and B now sees A’s address info all over the place.
This leads to a whole set of different problems for you. B places an order but the order is assigned A’s Shipping or Billing address. B gets an order confirmation email and freaks out as his items are being shipped to A.
Not only does this demonstrate a privacy violation, it inconveniences the store admin as the orders table, and customer records within your admin area are now inaccurate. You may be able to handle this situation, but imagine the same scenario with user C, D, E, F…
Welcome to Freddy Krueger’s osCommerce nightmare on osHelpers’ street. You’d be surprised how often we run into situations just like the one described above.
Wait, it get’s worse…
Let’s assume for a moment that you are accepting credit card payments right on your checkout_payment.php. Guess what’s going to happen if you have more than 1 user logged in using the same session ID and trying to checkout?
I rest my case.
So, what should you do? What can you do?
Go to store configuration within your admin area and enforce cookie usage. While this puts an end to the session ID problems, it may also prevent visitors from navigating your store properly due to strict cookie usage settings within their browser. In some cases, users may not even be able to add an item to their cart or checkout.
Navigate to the osCommerce contribution section and do some research to see what’s out there to prevent this nightmare from becoming a reality.
Session ID removal for Search Engine Spiders is part of a SEO Package which we offer. That would be SEO Pack I.
Keep the following in mind:
If you already have URLs with session IDs indexed on search engines and decide to eliminate the session IDs for search engine spiders, it’s not going to happen instantly.
Depending on the overall PageRank of your store, it may take the robots some time to come back to your site and re-index all URLs, then report them back to the datacenters and wait for the SERPs to update. This process can take days or weeks.
During the time the search engines revisit your site and update their index, we suggest an immediate tweak, which will enforce UNIQUE session IDs for EVERY visitor, even if they enter your store using a URL which has the session ID already appended. This will put an end to your problem instantly and assure that no privacy violations take place due to session IDs. If you want to find out more about this tweak, please open a support ticket.