That's a good question. I'm not sure what is the answer. I'll do some research and get back to you if I find an decent answer. You should email the people at iPage as they probably could help you..
What typically happens is that both users got to your iPage site by clicking on a link that contained a session ID. If you don't use Prevent Spider Sessions and keep the spiders.txt up to date, search engines will create and store session IDs in their index...
How do I make sure that my spiders.txt is up to date?..
, download the zip file, and replace your includes/spiders.txt with the one contained within. Check that contribution for updates - I will keep it current with new spiders I see...
OH, OK. I did that. I just didn't know if there is some iPage website that we could go to to update that list. Didn't know if there were people out there that watch that kind of thing all the time and have tons on a list (since you said that you weren't trying to list all spiders ever made)..
There are several places I know that have a VERY large list of spiders and their user agent strings. The sources for the free.
Has one it uses. But I don't recommend this route. The longer you make spiders.txt, the more processing is done EVERY TIME a page loads on your store. I think it is useful to list spiders that are currently active, which is what I try to do. Of course, I can't guarantee that I see all of them, but it is better than leaving it as stock (you'd miss msnbot, two Yahoo bots, and more.)..
I find that this is still happening even though I have the spiders.txt file updated and enabled. Is there possibly any other setting I may need to check to stop people from finding other users logged in. For reference here are my sessions settings:.
Session Directory /tmp.
Force Cookie Use False Info.
Check SSL Session ID False Info.
Check User Agent False Info.
Check IP Address False Info.
Prevent Spider Sessions True Info.
Recreate Session False Info.
I have now also set :.
But if any can suggest changes to my sessions settings in admin please let me know...
I'm finding this VERY confusing, with a lot of conflicting advice. Today a customer logged into my client's MS2 iPage site and requested a new password. She was a repeat customer from Maryland with THREE separate accounts over the last three years, and apparently with two different addresses in those three accounts. However, in all three accounts, she used the same credit card for her orders. She placed an order only last week..
Somewhere in that same time frame (not completely sure on that) a new customer from New York came on board and found items she liked. She put some items in her cart and went through the checkout procedure. She entered her name, address, and information, and paid for her order with a Master Card (totally different number). Somehow her order was attributed to the first customer in Maryland. The order shows the first customer's name and address and email address...BUT lists the second customer as the billing and ship to address, and uses a totally different brand credit card. The order does NOT show the second customer's phone or email address..
What in the world happened to mix these two up this way? And how to prevent it from happening again? On another thread, the advice was to set.
Check SSL Session ID to True.
Check IP Address True.
Prevent Spider Sessions True.
Recreate Session True.
What's the correct setting for this when you have a shared server??..
Mom2nine - - this may not be a session issue at all. There is a known bug (link to follow) where the address book can get corrupted..
What happens is that the osC uses the 2nd customer's addres information to overwrite the address book entry that the 1st customer used. Then, whenever customer1 or customer2 place an order, it will use the same address book entry, and hence show address/shipping info for customer2 whether customer1 orders or not..
For some more details..
Thanks, but I'm not sure where that address book update script is located. Can you direct me?..
Are you storing your sessions in a file folder e.g. tmp, or are you storing them in your database? On a shared server you should always store them in the database. Check the last line of both of your configure.php files to make sure that they read.
It's been set to mysql since day one. From what I'm reading, the problem seems to have to do with customers finding the iPage site through a search engine link that includes a session ID. The client's iPage site was deeply indexed by the search engines back before the session ID issue was fixed, so there are a lot of links floating around out there with ID's in them. Is there a way to get those links removed or corrected? Or is there a solution that keeps the old session ID's from being used when someone is coming in?..
The only solution that I know is to make your iPage site IP based and install a full ssl certificate. You can then turn on the 'Force Cookie Use' feature which will get rid of session ids. This works okay with the PayPal IPN module, but does not work with at least one other payment module (but this is for a UK based bank so shouldn't bother you)..
Appreciate the insights, you're probably right on that. I'll pass it along to the client and see if we can get that in the works...
I have had this happen twice now (on two totally different servers) and was wondering if anyone had experienced the same and if there may be a solution..
A customer reported to me that when they went to my iPage site to place an order they found themselves logged in as another user. Thankfully they logged the other person out and logged in as themselves. This happened once before when my server was overloaded with customers because of a special I was having - and I put the error down to that but now that it has happened again I am looking for a solution..
Note that these people were definately not using the same physical machine. I am waiting to determine if maybe they use the same ISP or there is some thread that binds them.
Has anyone else experienced this or is there some setting in the admin section that will stop this from happening?.
I've had this problem as well and would love to know how to resolve it...