Help! Store is using wrong customer details!

[Gemini05]

We've been running an OsCommerce store for about 2 years now with no problems, but it has started doing something strange just recently and I have no idea what has happened - we haven't made any major changes to the site, besides adding new products.

 

When a customer places an order, the cart is sometimes adding "Customer Details" that are from a previous customer - not the one placing an order. Ie. "Customer Details" will be customer #1, "Shipping Address" will be customer #2, and "Billing Address" will be customer #2.

 

This doesn't happen on each and every order, but has happened on about 3-4 orders in the last month and I would like to make sure that this doesn't keep happening.

 

PLEASE HELP! I don't even know where to begin to look to see what would cause this.

Click here

to see our store. (Store name not added to post so search engines don't pick it up.)

[Guest]

It sounds to me like a sessions problem.

 

In order for anyone to help you, please log in to your administration page, go to Configuration > Sessions, and copy the information there and paste in this thread. Then, open this file in a text editor: catalog/includes/configure.php and copy the top part of this file (*not* the database connection settings and passwords) into this thread also.

 

This will help people to troubleshoot your problem.

 

Matt

[jasonabc]

Admin > Configuration > Sessions

 

Set Prevent Spider Session and Recreate Session both to true.

[mattyhew]

Admin > Configuration > Sessions

 

Set Prevent Spider Session and Recreate Session both to true.

 

I know someone woth a similar problem. Has this been tried on the site in question yet? I would very much like assurance that this will be succesfull.

[modomo]

I set both permissions to true as recommended above, but have still had the issue with a couple of order from this weekend.

 

Does anyone have other recommendations????

 

Lyndon Modomo

[Guest]

Isn't it about time this was resolved?

 

If you read the forums there are dozens of stores experiencing similar problems, ie customers information being mixed up/customers being able to see personal details of other customers, but there is nowhere on the OSCommerce site that deals with it. All of us are spending hours trawling through forums searching for possible solutions and just when we think we have found the answer we find that we have reached another dead end! Similarly we find that some so called "solutions" may even cause further problems.

 

Unfortunately, a large proportion of readers are not programmers, so find it difficult to sort the useful information from the not so useful (possibly even harmful) guidance about sessions SIDs etc. But it would seem to me that there exists a basic flaw in OSCommerce that allows serious breaches of security of personal data, by allowing customers to view one anothers information. I am sure that there are a large number of us who want to know how to deal with this.

 

Why isn't it being taken seriously? What we need is the OSCommerce team to post the solution in the documentation on their website. This would save hours of time for those of us trying our best with limited knowledge to find a solution that actually works. It is my opinion that this issue is serious enough to warrant this.

[jasonabc]

But it would seem to me that there exists a basic flaw in OSCommerce that allows serious breaches of security of personal data, by allowing customers to view one anothers information. I am sure that there are a large number of us who want to know how to deal with this.

Whilst I sympathize with the problem (and the solution I posted above should have solved it) I do get a little tired of inexperienced users not being able to fix a (usually self-inflicted) problem and resorting to "software-bashing". It is worth noting that I've done almost 30 OSC stores. With tens of thousands of customers that take hundreds of thousands of dollars a year in sales I have never experienced this problem *once*, on any of my stores. Whilst it may be easy to start "software bashing" it is fair to point out that inexperienced users seem to be having this problem because it is their inexperience that has led them to change something in OSCommerce which is now causing this problem. Maybe a contribution has been installed incorrectly? Maybe one of the contributions themselves is causing this? Or a bit of code or something in the database has been incorrectly changed that is seeing this issue raise its head?

 

My point is that OSCommerce *does not* contain this flaw out of the box. If it did - every single person that used it (myself included) would have this problem. That points to the problem being entirely self-inflicted. Something has been changed, or something incorrectly installed by the user that is seeing this issue occur. I can't tell you what that is - I don't know what's been installed or what's been changed on any of the stores having problems. I do understand your frustration as this of course is a big problem - but please try and be open to the fact that the problem has been created by you at some point in the development of your store rather than a bug in what is a stable and well-respected e-commerce application.

[Guest]

Whilst I sympathize with the problem (and the solution I posted above should have solved it) I do get a little tired of inexperienced users not being able to fix a (usually self-inflicted) problem and resorting to "software-bashing". It is worth noting that I've done almost 30 OSC stores. With tens of thousands of customers that take hundreds of thousands of dollars a year in sales I have never experienced this problem *once*, on any of my stores. Whilst it may be easy to start "software bashing" it is fair to point out that inexperienced users seem to be having this problem because it is their inexperience that has led them to change something in OSCommerce which is now causing this problem. Maybe a contribution has been installed incorrectly? Maybe one of the contributions themselves is causing this? Or a bit of code or something in the database has been incorrectly changed that is seeing this issue raise its head?

 

My point is that OSCommerce *does not* contain this flaw out of the box. If it did - every single person that used it (myself included) would have this problem. That points to the problem being entirely self-inflicted. Something has been changed, or something incorrectly installed by the user that is seeing this issue occur. I can't tell you what that is - I don't know what's been installed or what's been changed on any of the stores having problems. I do understand your frustration as this of course is a big problem - but please try and be open to the fact that the problem has been created by you at some point in the development of your store rather than a bug in what is a stable and well-respected e-commerce application.

 

Unfortunately, it contains this flaw "out of the box" See the oscommerce.sql here:

http://www.oscommerce.com/solutions/downloads

 

INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) VALUES ('Prevent Spider Sessions', 'SESSION_BLOCK_SPIDERS', 'False', 'Prevent known spiders from starting a session.', '15', '6', 'tep_cfg_select_option(array(\'True\', \'False\'), ', now());

Default is "false" which will allow the spiders to crawl the site with sessions and may cause the problem described as visitors get into the site from search engines.

 

but there is nowhere on the OSCommerce site that deals with it. All of us are spending hours trawling through forums searching for possible solutions and just when we think we have found the answer we find that we have reached another dead end! Similarly we find that some so called "solutions" may even cause further problems.

There are contributions however and are mentioned in the forum threads. Use the session regeneration to get around it.

http://www.oscommerce.com/community/contributions,4112

[Guest]

My point is that OSCommerce *does not* contain this flaw out of the box. If it did - every single person that used it (myself included) would have this problem.

 

Well I appreciate what you are saying about inexperienced programmers using OSCommerce, however, this is a serious issue being experienced by dozens of people, not just one or two. Surely, there must be a reason why we are all experiencing the same problem? Is it possible, for example, that shared SSL certificates is the cause in which case we can't really be blamed? If you read the threads there seem to be several alternatives for setting up your configure file, could one of these be correct while the others are red herrings? Which brings me back to the point I made about being able to separate good from poor advice.

 

It is my opinion that because this is a widespread problem which comes up time after time in the forum there must be a global solution, one that could be set out on the OSCommerce website. I'm sure all of us novices appreciate that we will on occasion "break" our site and have to do some hard work to bring it back together, and any help from others is very much appreciated. However, given the widespread nature of this security issue I don't think it fits into this category. What we need is for the OSCommerce team to really look into this problem and offer some alternative solutions that we know are reliable.

[jasonabc]

Unfortunately, it contains this flaw "out of the box"

I think this is a grey area Mark. Since this option is configurable through Admin it's arguable that it is an out of the box "flaw". The CDT must have had good reason for making this option configurable in the first place and setting it to 'false' as the default value - especially since the OSC Knowledge Base article on this area recommends setting it to "true" for the very reasons the OP is experiencing.

 

I realize 'out of the box" means before you have touched it - but you have to change OSC code to even get it working in the first place (config files?) so does that change mean it's no longer an out of the box install? You certainly couldn't run a vanilla OSC install as a proper online store - you have to configure it first. Preventing spider sessions should be part of this configuration so in my opinion it's not an out of the box "flaw" (although I do understand it can be argued that way).

[Guest]

Well first of all is there a reason for this switch to exist? I do not understand why is there. It can be easily overlooked even when you're familiar with the osc.

 

Another problem is that unlike other configuration settings which may bring some sort of error, the function of this switch is transparent. Till you find out your pages are indexed with sessions from spiders and then you are in trouble. Not only your customers can mix up their accounts/cart contents but your seo rankings are grounded for duplicated content and no idea how long this can last.

 

And if there is a good reason for this setting to be there and by default set to false then I am all ears. Outdated spiders.txt by itself can cause enough grief.

[yvnolan]

Does anyone know how to fix this problem in MS2.1?

I cannot see Sessions in the Admin Panel. Have taken a quick look at the Register Globals contribution but this only appears to work with MS2.2. Many thanks.

[aaanativearts]

I turned on both the Spiders and Regneration switches to True, but I still have this problem. I also noticed in my address_book database table that the address book ids and customer ids don't match and are all over the place. One customer id might be 5 off from the address book id, others are off 20. Could this be related to this problem? I've run this site for 2 years without this problem with oscommerce standard edition, then a few months back I switched to oscMAX 2.0RC3, and it worked fine until the last day or two, and now all at once it has started having this problem. I did have the Search engine switch on True and Regeneration switch on False until reading this topic's posts and allowed checkout without an account. I switched it today to must have an account and login, and both Search Engines and Regeneration to True, but that didn't fix it, either.

[otgrouch]

Good to see it's not just me...

 

I installed OSc in August, 2005. Before the end of 05, I installed 'Dangling Carrot' and 'CCGV'. Since then, I have done nothing to the store except add products and process orders.

 

This past weekend, I got an order that had one comma in both the billing and shipping address fields - nothing else. There was information in the customer information field, but no billing or shipping addresses. I never got payment for it, and the customer emailed to say that they had not placed an order....so I deleted it, figuring it was a fluke. Monday, I got another order just like it - but a different customer.

 

I did some research and found out about the 'spider sessions' setting, which had been false since the store was installed. I changed it to true. Next day, I get an email from another customer saying that he went to the store and found himself logged in as someone else. At this point, I set 'Force cookie use' to true this morning. No issues during the day...but no orders either. Around 6pm, I get a call from someone trying to buy something - but everytime he goes to check out, he gets logged out. I log into his account and try it and the same thing happens. Change 'Force cookie use' to 'false' again and it starts working.

 

Within 2 hours of turning cookies off, I get 3 more orders. Two of them are from the same person, but one has a billing address for someone who lives 1000 miles away. Call both customers to find that the billing address belongs to the customer who actually placed order #2, not the customer who the order was logged under in the catalog.

 

While my problem is not as large as some have reported, I too am kind of surprised that there isn't a definitive answer to this issue. I've found reports of it happening that go back 3 years, but not a single one has an answer that fixes the problem. A fix for something like this should be a priority IMO...and I'd appreciate any help I can get!

[jasonabc]

Don't forget that if someone has posted a link to your store that includes their session ID then whoever follows that link will assume the same session ID and activity. This includes login and account information.

[otgrouch]

I specifically asked the customer I called last night how he came to the store. He said that he typed in the URL himself, without following a link or bookmark.

 

I understand that I could still have spider sessions with IDs lingering out there, but when I'm told that no link was used to come to the store and it still happened I have to believe it's something besides spider sessions.

[satish]

oscid is the only reason data can get get shared.

 

So setting regenrate session id on login will take care.

Also setting a chek for browser and IP will help further.

 

So in admin>>configure>>session set thise to true.

 

This had been suggested in this thread but I repeated with some additional comments.

 

 

Satish

[otgrouch]

Thanks. I've set both of those to true...I will see if that takes care of it.

 

Is there some reason these two variables aren't set to 'true' out of the box??

[Innoventor]

I know my hosting company posted a notice for osCommerce users. They said that if you have Caching enabled in osCommerce on a shared server (which applies to most of us), the default directory that osCommerce uses (/tmp) could cause cached data to get mixed up between stores. They said if you have Caching enabled, to set the /tmp directory in your cgi bin folder and you should be fine.

 

I notice the Sessions default directory is also set to /tmp. I'm no PHP-Web programming expert (I'm experienced at C Win32), but maybe the Sessions default directory might be causing problems on shared servers in a similar way that Caching does. This might also explain why some people don't have problems with osCommerce until some seemingly random point, when maybe someone else sets up an osCommerce store on the shared server that you're using.

[satish]

Always store sessions in data base so this will not come in.

 

Satish

[otgrouch]

Well....it worked for a week.

 

I have 'Prevent Spider Sessions' and 'Recreate Session' set to true, but just got a call that my store was 'all messed up'.

 

I typed in the URL to the catalog and found that it came up with over $500 pre-loaded in the cart and I could view a user's information. It's as if he didn't log out and anyone coming to the store became him.

 

I logged out from that account and now it comes up normally.

 

Suggestions? This is turning out to not be such a simple fix....

[otgrouch]

Looking closer, it appears that the store is assigning the SAME oscid to everyone until they log in. If that person doesn't log out, anyone coming to the store gets logged in as them.

 

If I go to my store right now and refresh the page, the number of items in the cart keeps increasing - and all I'm doing is hitting refresh! I'm seeing other people load up the cart!

[otgrouch]

This is just getting frustrating.

 

The store is not generating new session IDs. I have turned cookies off on my browser and cleared my cache. When I go to the store, I get the same session ID that I've been seeing since this started.

 

I installed 'regenerate session' and it did nothing. Still the same session ID.

 

I was able to sit at my computer and, by simply hitting refresh on my browser, watch a customer from product selection to checkout. I then had to log him out to clear his personal information out of the system.

[satish]

apart from regenerate session id the other points like chek IP AND chek browser needs to be set to true.

Also set kill spider session to true.

 

 

Satish

[otgrouch]

apart from regenerate session id the other points like chek IP AND chek browser needs to be set to true.

Also set kill spider session to true.

Satish

Kill spyder session has been set to true for about a week. Changing 'check IP and Check browser' to true puts the user in a login loop, never letting them onto the page.

 

Every time I go to my site, I get the same session ID. If I clear cookies, turn them off, clear my cache, etc...it's still the same oscid. If the software isn't generating unique IDs for all visitors, it's easy to see why this problem is happening.

 

Even with 'recreate session' set to true and the session regeneration contrib installed, I have the same session ID after logging in.

 

My store is at http://twosrus.com/catalog The oscid that it always gives me is a5393ba15b3d6fbc1299722f8b598eea