Fake Phantom Spam Customers? CAPTCHA No Help

We just rolled live on a custom cart for which we spent 3 months migrating and customizing the front end. Front end. No customizations to the Admin except as below (CAPTCHA). Now that we are live we are receiving what we think is customer spam. Every day we receive many "new customers" sometimes hundreds with legitimate sounding names but with the caveat that the records are deficient in such a way that we can see the following PHP errors in admin/customers.php:

Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /var/www/html/admin/customers.php on line 1099
Warning: array_merge() [function.array-merge]: Argument #2 is not an array in /var/www/html/admin/customers.php on line 1101
Warning: reset() [function.reset]: Passed variable is not an array or object in /var/www/html/admin/includes/classes/object_info.php on line 29
Warning: Variable passed to each() is not an array or object in /var/www/html/admin/includes/classes/object_info.php on line 30

Real customers (our testing) show up fine, and do not throw these dependency errors.

Here is an odd thing: Going to the database, we see that looking at all the tables mentioned in select statements in /admin/customers.php: customers, email_archive (yes, turned on), address_book, customers_info, coupon_gv_customer, reviews (turned off), group_pricing and zones, we see no reference to the names that appear in our "New Customers" list in Admin Home. Clicking these generates the errors. If we sign up nicely in a test, we see the information show up fine in the first 3 tables.

I have checked the FAQs and searched the terms related to "customer spam" "fake customers" and related terms. Search results are nil.

I chose Business Issues > Fraud Prevention, hopefully correctly, please re-route if incorrect.

Using Zen Cart 1.3.8a at Westhost; Linux, Apache 2, PHP: 5.2.92 MySQL 5.0.67. It was a default installation. Because of deep customizations, we have refused upgrades.

CAPTCHA: We first installed this: http://www.zen-cart.com/forum/showthread.php?t=42780 But that didn't seem to work very well for us, so we tried our best to uninstall.

Then we installed this: http://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=1306

And it seems to be functioning fine for New Account Registrations. This does not touch the Contact Us form. Smoother installation if I may say so.

We are sifting through a bunch of noise to collect our real orders. Advice? Thanks much.

You have entry_country_id data in the address_book table for those customers' records. That's almost always caused by importing customer data using some sort of broken tool to load the data. Or you've manually altered data or data structure in the database and broken something in the process. Or deleted countries from the countries table without ensuring that those country values weren't already in use. Or deleted and re-added country records not realizing that doing that assigns new numbers and throws things out of sync, resulting in symptoms similar to what you quoted.

:oops:
Just why exactly removing countries from display would be critically important to displaying which customers were new today is Object Oriented Genius beyond my simple country doctor understanding of such matters.

Just another nail in the coffin of Zen Cart for this small-time web developer. Seriously looking at paid software. The bloom is off the rose and the worm has turned: open source has gone amok and professionally maintained software is once again the future.

Thanks much for your reply in any case. I hope this helps somebody else whose boss told them: get rid of those countries on that silly pulldown list....we ship only to continental US, not Albania or Andorra.

bamboohq:

Object Oriented Genius beyond my simple country doctor understanding of such matters.Sorry, it has nothing to do with Object Oriented anything.
You can thank the authors of osCommerce for that design decision.
It's slated for revamp as one of several inherited things that we know need reworking.

bamboohq:

Seriously looking at paid software.As you wish. Glad you had fun with your foray into other avenues.

bamboohq:

I hope this helps somebody else whose boss told them: get rid of those countries on that silly pulldown list....we ship only to continental US, not Albania or Andorra.
Deleting the likes of Albania or Andorra from the list of countries wouldn't affect things the way you described above.
But deleting everything en masse and then manually adding new country records would ... since "new" records get new internal numbers, and it's those internal numbers that your old customer records would be pointing to.

It's fixable, but since you've already decided to convert to something else, I won't bother with the trouble.

I should also point out that no tool was used for importation. Rolling back to original countries table changed nothing; the entry_country_id field always agreed: 223 == United States.

Bogus errors still present.

Lastly: It was noticed that these "new customers" are actual former customer IDs that show up in the Customers > Customers listings. But the Account Created date is new, and no data is reflected there.

Please pardon my rant against OOP. I have a thing about deliberately obscure software. It is like a secret club where everybody tries to outdo each others' cleverness and all it does is result in a giant mess and low productivity. Zen is a victim of contributors who think like this.

Right. So more research has revealed that while country information is not at issue, agreement between customers and address_book tables IDs are at issue. Fix0r:

UPDATE customers c, address_book b SET c.customers_default_address_id = b.address_book_id WHERE c.customers_id = b.customers_id

Fixed the breakages with the PHP error messages. :censored:

New/same problem: The sort order of the "new customers" in Admin Home is seemingly reporting the date as today. That is, they all say (for today) 8-31-2009. But they haven't been touched in months. So then the question gets more silly: why is it that when I go to Customers > Customers and perhaps search "Johnson", then click Admin Home, all of my "new customers" are all suddenly named Johnson and they became "new" on 8-31-2009? Then if I go back to Customers > Customers and see them all, then Admin Home, we are back to most recent on top? Quirky buggy time sink. I would rather Twitter.

Well, yes, a mismatch between all your address book entries vs customer entries would certainly cause a similar set of symptoms. That's way more serious than altered records in the countries table.

I would suggest backtracking to find the point in time when that relationship worked correctly and then figure out what you did to break it. And probably restore the good data and rebuild from there.

HERE IS THE AHA! MOMENT you have been waiting for: Simply VIEWING the customer record in Edit mode or Customers > Customers is enough to generate an essentially blank record for the customer in the table customers_info, which applies the datetime stamp at that moment.

Here is the insertion dump of the table which I truncated before discovered this:

INSERT INTO `customers_info` (`customers_info_id`, `customers_info_date_of_last_logon`, `customers_info_number_of_logons`, `customers_info_date_account_created`, `customers_info_date_account_last_modified`, `global_product_notifications`) VALUES
(682, NULL, 0, '2009-08-31 22:37:40', NULL, 0),
(327, NULL, 0, '2009-08-31 22:37:40', NULL, 0),
(550, NULL, 0, '2009-08-31 22:37:40', NULL, 0),
(1095, NULL, 0, '2009-08-31 22:37:40', NULL, 0),
(1863, NULL, 0, '2009-08-31 22:37:40', NULL, 0);

Each of those null entries happened as a result of simply browsing Customers > Customers.

Let me repeat clearly what I am asserting: /admin/customers.php receives a cold call. /admin/customers.php inserts records into the table customers_info that correspond the viewed pages of customers. Pretty wild huh?

These customers are in no way "new." This is a dramatic flaw.

Keeping the database in sync...wow.

// Lines 1085-1091 in my /admin/customers.php
// What follows is Zen code

// if no record found, create one to keep database in sync
      if (!isset($info->fields) || !is_array($info->fields)) {
        $insert_sql = "insert into " . TABLE_CUSTOMERS_INFO . " (customers_info_id, customers_info_number_of_logons, customers_info_date_account_created)
                       values ('" . (int)$customers->fields['customers_id'] . "', '0', now())";
        $db->Execute($insert_sql);
        $info = $db->Execute($sql);
      }

In sync? In sync with what?

So my ultimate fix is this:

1. Comment out the insert SQL PHP in customers.php;

2. Truncate the customers_info table and run:

INSERT INTO customers_info ( customers_info_id, customers_info_date_of_last_logon, customers_info_number_of_logons, customers_info_date_account_created, customers_info_date_account_last_modified ) VALUES ( SELECT customers_id FROM customers, NOW(), 0, NOW, NOW() );

This gets me all my migrated customers in one place. "In sync" as they apparently say. New customers register and are added here by other methods, so I am not worried that I have trashed junky code.

This insert instead of update is flawed code and needs revision. The upshot is that it reports that you have "new customers" when all you really have is a report of what an admin recently looked at in the Customer list. Those names don't pay the bills like regular customers do.

BTW, I tried to post this thread in Bugs after I realized where it was going, but was informed that "we don't cross-post in this forum" and my thread was summarily closed. Somebody may wish to migrate this under a different heading though, because the way I see it, this is a bug.

bamboohq:

So my ultimate fix is this:

1. Comment out the insert SQL PHP in customers.php;

2. Truncate the customers_info table and run:

INSERT INTO customers_info ( customers_info_id, customers_info_date_of_last_logon, customers_info_number_of_logons, customers_info_date_account_created, customers_info_date_account_last_modified ) VALUES ( SELECT customers_id FROM customers, NOW(), 0, NOW, NOW() );

> **bamboohq:**
>
> This gets me all my migrated customers in one place. "In sync" as they apparently say. New customers register and are added here by other methods
Again, adding "customers" by "other methods" is your root problem. 
If your "other methods" were to add "customers" to all 3 tables correctly then you wouldn't have need for this whole discussion in the first place.

By "other methods" I simply meant customers adding themselves by routine account registrations. With my method after a migrations, once a record exists in customers_info, the invaluable information that is tracked there is updated "by other methods" and not by insertions of new records by the mere action of VIEWING the Customers > Customers page.

Are you defending that the Admin Home text in 1.3.8a says to store owners "New Customers" when they are nothing of the sort?

I tested new singups. The thing behaves as advertised with my fix. Take it for what it is worth: free.

I'm glad you've found a solution to your problem.

However, since the symptoms you describe can't seem to be duplicated on a fresh clean install of v1.3.8a, there's no bug to fix, and suggests that whatever "migration" you're talking about may be the cause of your problem.

Thanks for your free advice. Hopefully someone will find it useful.