Same session ID used for 2 customers?

[rgcote]

We are having a problem where the same session ID is being assigned to more than one customer. I have posted a previous message about the symptoms we were seeing (http://www.oscommerce.com/forums/index.php?showtopic=70698).

 

Now it looks like the root cause of those problems is that the same session ID is being assigned to multiple customers so that during checkout items are being put in the wrong shopping cart and credit card charges are being placed against the wrong customer.

 

Currently, we have the following settings in our catalog configuration file:

 

define('HTTP_SERVER', 'http://www.bluewonder.us');

define('HTTPS_SERVER', 'https://mmm1113.verio-web.com/bluew8');

define('ENABLE_SSL', 'true');

define('DIR_WS_CATALOG', '/catalog/');

define('DIR_WS_IMAGES', 'images/');

define('DIR_WS_ICONS', DIR_WS_IMAGES . 'icons/');

define('DIR_WS_INCLUDES', 'includes/');

define('DIR_WS_BOXES', DIR_WS_INCLUDES . 'boxes/');

define('DIR_WS_FUNCTIONS', DIR_WS_INCLUDES . 'functions/');

define('DIR_WS_CLASSES', DIR_WS_INCLUDES . 'classes/');

define('DIR_WS_MODULES', DIR_WS_INCLUDES . 'modules/');

define('DIR_WS_LANGUAGES', DIR_WS_INCLUDES . 'languages/');

 

define('DIR_WS_DOWNLOAD_PUBLIC', DIR_WS_CATALOG . 'pub/');

define('DIR_FS_DOCUMENT_ROOT', '/');

define('DIR_FS_CATALOG', '/catalog/');

define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');

define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');

 

define('DB_SERVER', 'www.bluewonder.us'); empty for productive servers

define('DB_SERVER_USERNAME', '**********');

define('DB_SERVER_PASSWORD', '**********');

define('DB_DATABASE', '********');

define('USE_PCONNECT', 'false');

define('STORE_SESSIONS', 'mysql');

 

In the Configuration->Sessions section, we have the following settings:

 

Session Directory: /tmp

Force Cookie Use: False

Check SSL Session ID: False

Check User Agent: False

Check IP Address: False

Prevent Spider Sessions: False

Recreate Session: False

 

I am tempted to switch to file based session storage. Anyone have a suggestion for why this would be happening? We are on a shared server with a shared SSL certificate. Could it be that the level of traffice we are experiencing is too much for the shared server and it is getting our users confused?

 

This behavior has only been in the last month or so but we have seen a large increase in traffic and orders over that period of time.

[Guest]

enable cookies, and ssl session id, also where and what are you setting for cookies in the other config file? this should help. also, have your users clear their cache.

[rgcote]

Okay, but I read somewhere in these forums that if I enable the Cookies and the Session ID that AOL users will have difficulty ordering through the shopping cart. As much as I'm not a fan of AOL ;) , there are a sizeable numbers of consumers that use AOL and I don't want to prevent them from purchasing our products.

 

Am I off base here?

[rgcote]

So I tried those settings. When I set "Force Cookie Use" and "Check SSL Session ID" to both be true, there is one problem. If a customer puts items in the shopping cart and then logs in, OSC tells them the shopping cart is empty. Then when they hit "Continue" the items show up.

[Guest]

AOL has no problem with cookies. Not sure about how it affects SSL session IDs. Melinda (modom) posted the results of checking all the settings a while ago. I remember that FORCE_COOKIE_USE was one of the settings that worked. Not sure about SSL session IDs.

 

You may want to check your COOKIE_PATH and COOKIE_DOMAIN settings. Note: you can set both COOKIE_PATH defines to '/' safely. The two COOKIE_DOMAIN defines should be

define('HTTPS_COOKIE_DOMAIN', 'mmm1113.verio-web.com');
define('HTTP_COOKIE_DOMAIN', 'www.bluewonder.us');

Hth,

Matt

[goldcoins]

BTT

[threeG]

Given the dropoff in responses to this thread I am not sure how the problem was eventually resolved - if at all.

 

However, I have noticed that such posts have shared SSL certificates in common.

Anyone else made the same observation?

 

Regards,

John

[rgcote]

We actually have not yet resolved the problem and it is a major problem resulting in quite a number of irate customers.

 

It should be noted that we are using the following contributions:

 

- Gift Voucher/Discount Coupons

- Tracking Numbers for FedEx, UPS and USPS

- Some additional sales reports

- Order ID showing on invoices

 

I updated our site to use the latest MS2 release. That didn't solve the problem. I have been trying to get the contributions above to work with a recent CVS snapshot and it has been quite a challenge.

 

So as things stand, the problem still exists. We are hosted on Verio with a shared SSL certificate. This problem seems to happen most when there are a number of people logged into the site at once.

 

Here's what we are actually seeing: someone will select a product and then checkout. During checkout, they register. During the remaining check out process, they suddenly see some other customers information. We have not yet seen a situation where the wrong person's card was charged but we have plenty of situations where the order is recorded against the wrong account.

 

This is most often how things are going wrong. Anyone have a clue? Will getting a dedicated SSL certificate help? Will moving to a dedicated web server help?

 

Any help or suggestions would be very much appreciated. We are in a pretty bad place.

[bloodshoteyes]

I think that this problem has resolved when the switch was made to a dedicated SSL certificate. I had this problem sometime ago with a discount hosting company and found that there were seven of us piggybacked by the host. Its alot like have multiple databases on your site. I think, but not sure, multiple users in the same root dict, compounded when a shared SSL is in place.

 

I would love to know the cause if any one has the answer... I just guessing...

[user99999999]

Hi,

 

The first step it to remove the hard coded session id 3ff6a... off your main page and your products page.

 

Register with our new ONLINE STORE and receive a FREE 1 oz tube of Blue Wonder? Gun Cleaner!  (You pay only $3.78 for Shipping) Check out other special offers on combo kits!

[♥stubbsy]

I have the same problem. On my current site it is not a big issue as the products are high value and we only have a few purchases a day, I know the problem exists tho as when viewing who's online someone is shown as being there continuously, although the IP addy changes, i.e the session is being passed from one customer to the next.

 

However on a shop I was running a few months ago where the sales volume was high we experienced the same as you with incorrect customer information being recorded against purchases. In fact the first person to buy on the site one day was shown as buying 6 items at different times during that day. It was only when I realised that the credit card information was different for each purchase that I realised the problem.

 

Unfortunately I do not know how to fix it, but would hope that someone can help.

 

cheers

 

stubbsy

[rgcote]

Can you tell me whether you are on a server with a shared SSL certificate or do you have a dedicated SSL certificate? If it is shared, then that will help confirm my suspicions and we'll try using a dedicated certificate.

 

Thanks for the feedback.

[user99999999]

Hey Rob

 

Your problem is the hard coded session id on you main page and products page.

[♥stubbsy]

Unfortunately I don't use either as we use a 3rd party to process the transactions so have no need for the secure site.

 

Hopefully we can get to the bottom of this as I have asked quite a few times in the past and had no response.

 

I did have the problems with AOL users as well initially, where they could only see the login page when they entered the site.

 

The settings i used to solve that problem was

 

Session Directory /tmp

Force Cookie Use = True

Check SSL Session ID = False

Check User Agent = True

Check IP Address = False

Prevent Spider Sessions = True

Recreate Session = False

 

I don't know if that is of any use, but i guess the more information we can look at the higher the chance of solving it :)

 

cheers

 

stubbsy

[♥stubbsy]

For what its worth. I have just moved my site to a new host and I no longer have the problem.

 

I have made no changes to the site or configuration between moving servers.

 

My original host where I have had the problem on 3 OSC strores was with Webfusion (UK) and my new host is clook.net who are also in the uk.

 

Maybe this will help someone if they can figure out what the differences are between the 2 servers?

 

Bye

 

stubbsy

[rgcote]

It appears that we have resolved the problem. We haven't had any re-occurences since we made the changes so I'm hopeful that we fixed it.

 

For the benefit of others, here's the resolution. The key to the fix was the posting from Dave (user99999999). My company had added a shopping cart to the customer's existing web site. So there were some regular web pages on the front of the site and the user is eventually led into the osc shopping cart.

 

My customer maintains the front end pages and had added a link on the home page that takes the user into the shopping section. Unfortunately, this was done by surfing to the shopping cart, copying the URL from the browser address bar and using that text as the href for the link on the home page. The URL that was copied naturally included the Session ID that was being used at the time.

 

So each time a new user came to the web site and clicked on that link to get into the shopping cart, they were given that same session ID. I had been spending all my time hunting through the OSC code and database trying to find a problem without realizing that a link had been placed on the home page with a hardcoded session ID.

 

Since we cleaned that up, the problems have not resurfaced. We are keeping our fingers crossed.

 

Thanks, Dave, for noticing and posting. It is *much* appreciated.

[revolutionsales]

Wow, much thanks to user99999999 and rgcote. I've been stumbling through code for weeks now, only to find that the problem was in a stupid html file. :huh: