upProblem of osCommerce session IDs in the links
A customer brought a problem to our attention today. They sent a newsletter to their subscribers an accidentally included an URL to one of the pages of their web site that contained osCommerce session ID.
This resulted into several of the subscribers seeing shopping cart of each other. An immediate solution was to block that specific session ID.
But lets see what happens in case a search engine spiders a link to some page of an osCommerce web site that contains session ID, or if such link gets included into a newsletter, again with session ID.
Each time a new visitor comes to the web site - osCommerce creates a new session, and then uses that session to store various variables, including customer’s login information if the customer chooses to log in. Shopping cart is also stored in the session. Sessions themselves can be stored in the database or in one of the folders (usually /tmp) on the server. In either case, session IDs being unique guarantee each customer works with that customer’s specific session and session variables.
What happens when osCommerce script finds a session ID attached to the link? What happens if a customer opens such link in the browser, and the link already has session ID? By default - osCommerce will try to locate a session with the same ID in its “session pool”. And if it succeeds - the customer gets access to the information stored in the session. If it can not find such session in the “session pool” - osCommerce will create a new session, but with the same ID as was specified in the URL.
So if a link with a session ID gets included into a newsletter, or is spidered by a search engine - two customers clicking that link in the same or almost in the same time (the difference depends on the server configuration, up to about 15 minutes by default) could actually share the same session, get access to the same user account, or share the same shopping cart contents.
That is why links should be only included into newsletter without session IDs, and sessions should not be started at all if its a search engine browsing the online store.
April 17th, 2007 at 11:21 pm
So how do I avoid this problem?
It is happening to me and I am not publishing a newsletter.
April 19th, 2007 at 1:06 pm
If your links got spidered with osCommerce session IDs, you may want to change the name of osCommerce session variable so that old session IDs would not count.
Please describe your problem in more details so that we could try to propose a more precise solution.
July 6th, 2007 at 9:37 pm
I just went through this at some length. The description of the problem is very real and effects many web sites (I tested one or two out to prove it wasn’t just my site). The problem is nothing to do with newsletters or spiders though. Most of our problems were caused by our sites popularily, our customers are networking and posting links on blogs and forums, many including session IDs.
The answer is to not ever have a session id as part of the URL visible to the customer. It appears (and I hope I am right about this) that the solution is to turn on “cookies” for the session IDs which turns off the session ID in the URL. This seems to be working OK.
Note that you also have to rename the session id variable, because all existing links will otherwise select the same session (as described in an earlier post).
All in all this is a real pain and I am surprised that the osCommerce team are not on top of it.
I also tried to avoid the problem by using the options to validate the IP address and browser. DO NOT DO THIS. The result is that whenever someone tries to follow the link they instead end up at your log-in page when the session gets invalidated. This will happen every time anyone visits the site via a link with a session ID, and you will see a huge number of exit pages as login.php (been there done that!)
If someone on the osCommerce team has any better suggestions please comment!
July 16th, 2007 at 2:03 pm
The main problem of osCommerce is some junk companies.
Keep away from Moneybookers, it’s the worst Internet company I have ever seen: you can’t withdraw your money and nobody wants to help you for months!!!
October 8th, 2008 at 5:22 pm
Forcing cookies does not work with authorize.net and for a lot of people who block cookies.
Setting the standard sessions flag to recreate the session after login prevents people who are using a common session ID via a link from actually sharing carts/account throughout checkout. (Although I am not 100% convinced there are not other issues associates with using that setting). This does not work with the Purchase without Account contribution of course.
November 12th, 2008 at 10:56 pm
Okay, Has anyone ever heard of POST variables? When I saw the osCID was being passed as a GET (query string) I was appalled. What else is insecure about this system? From a coding standpoint the backend is spaghetti and I am sure I will break it trying to find all of the GET requests and replacing them with POST and or forms. I understand that I get what I pay for when I use something free, but this is not an oversight. It is a beginner mistake. Does anyone know if there is a version of this software that has been modified to obscure variables relating to customer accounts?
September 8th, 2009 at 9:13 am
Is there a way to simply disable session ID’s long enough to run a sitemap crawl?