I would like to know the answer too. Anyone here know what is the answer to your question. I'll do some investigation and get back to you if I discover an answer. You should email the people at iPage as they probably know..
Since you mentioned session ID's, I had a look on the knowledge base to familiarise myself with them a bit more (new to this end of oscommerce), and found a definition of each of the settings, one of which was:.
If this is set to True then the session id will be recreated when the customer tries to checkout or login to their account. This helps prevent two customers from accidently logging into each others account due to hard coded session id's in the store..
So, I've set this to true and will monitor how it goes..
In the meantime, if there are any further thoughts, it would be interesting to hear..
Well ... it seems the problem persists.
Following the process as described before almost exactly, we have received two orders with mixed details. The only difference on this occasion was that both customers bought; customer A bought first, then remained online for 25-30 minutes, and then customer B placed an order..
I have looked through the forums for more info on this, and one suggestion I've seen is to force cookie use. This is set to false on my iPage site as I believe it puts people off purchasing, so would prefer not to force it, but is this the solution to the problem?.
I have a customer that has had this same problem 3 times in the last two days..
Has anyone determined a solution yet?.
No solution yet..
I have looked through the forums quite a bit, and the general consensus is that the session ID is the problem. It seems to be allocated to both customers in one way or another, thus giving the mixed details..
The way to bypass the problem is to force cookie use. That way, cart information etc., is recorder using the cookie instead of the session ID, and therefore cannot be interfered with. However, forcing cookie usage has it's own problems..
I have also checked the forum for a solution to the cookie problem, but as always seems to be the case, have never found the perfect solution for me. There are plenty of ideas out there, and most of them look like they will fix the symptoms I have, but it seems I already have the correct setup ... anyway, different problem, I will post a topic on that specifically to try and get some help. I will post a link to it here when I have done so..
Again, anyone reading this that has any further information, please feel free to share...
Just an idea, but are the customers coming from the same source? i.e. a search engine which has a session id stored in the link, and is therefore sending you customers with identical session ids....just a possibility......
Thanks for the replies..
I found the information about cookie usage. After reading the posts, I would rather not require their use. That seems to be the consensus, correct?.
The first thing we have decided to try is to store the sessionID's in the database. The setting we changed is in the config.php file. We changed that and have not had the problem yet, but we are monitoring the orders closely..
Yes, niknakgroup, that thought also occured to me. Do you know if there is a way to prevent search spiders from getting issued a sessionID?.
How is your session storage set in your configure files?.
If it's not set to mysql, try changing it and see if that corrects your problem..
define('STORE_SESSIONS', 'mysql'); // leave empty '' for default handler or set to 'mysql'.
In catalog/includes/configure.php AND in admin/includes/configure.php..
Yes, that is something I considered and have set prevent spider sessions to true, I made the change about 6-8 weeks ago and have just checked the pages indexed on Google, none of which have session IDs in them any more (there used to be quite a lot). However, if it was the case that a search result (or whatever) had a session ID set in it, would it not just be the same cart that different customers would see, or at most, the same customer details? In each event on my iPage site the details are different..
In both cases it is set to mysql..
In your admin section under configuration, there is a sessions link that will allow you to edit prevent spider sessions to true..
I think to solve this problem, I will have to set force cookie use to true, and try to figure a way of setting it up correctly. I wasn't sure about doing so at first incase it put customers off, but worded correctly, the cookie_usage.php page might not be so off-putting..
What do people think, is it best to force cookie use? If so, check out my post on cookie use to see the problems I have with that! LOL.
Thanks to everyone for their help so far...
Im soory to hear about your troubles but Im glad Im not the only one!.
For starters, I also installed Ian's sID killer (which is more potent than whats in MS2) plus set my session config to:.
I also set my configure.php files to store sessions in mysql..
Also make sure the ssl cookie_domain (HTTPS_COOKIE_DOMAIN) and non-ssl cookie_domain (HTTP_COOKIE_DOMAIN) is set to the same url as the SSL url (HTTPS_SERVER). It seems if these urls are set differently to each other, the session id is passed in the url. (someone might know more about this).
Please keep this thread alive in case this configuration causes more issues! (hopefully not...)..
Bah!! I spoke too soon!.
It seems sID killer made the cart un-useable...Force Cookie Use was scaring the customers...where's a fix to sessions class?!.
This is getting serious.....