Jack_mcs

@tonymazzRegarding the account details you posted, unfortunately, there isn't anything shown there that would allow the code to identify it as a fake account. While a person can look at it and see that it is fake, from a coding point of view, it is legitimate since it has valid entries for an account. I suppose a check could be added to see if the street address contained number and letters, or if just letters (which can happen) that it be at least two words. But that might be chasing a never ending list of possibilities. Another check could be to see if the state and country match. Those details are in the database so it would not be difficult to check them. I will plan on adding this as an option. Another check could be the post code. According to Wikipedia, the postal code of all countries that use one has at least one number in it. I will plan on adding this as an option. You don't mention if you are using the IP List option. If not, you should be. And make sure to set up a cron job for it or the list won't be useful. If you can identify some common letters that are not normally used, you can include those in the bad words option. For example, the suburb has an entry ending in "vxqd". I can't imagine word from any country using that. The entries in the fields are probably just randomly created so adding words like this may not help, or only a little, unless you are seeing them used over and over. As for sending emails, be sure you have the options set to block email addresses and url's in the forms. Depending on your version of oscommerce, there might be a setting to limit how often emails can be sent. By raising that number to something higher, like 30 minutes, it might make it difficult for the spammers to send out large numbers of emails. That's all I can offer on this sort of problem. If you, anyone, can see something else that should be checked, please post it here.

Based on this, it is obvious you haven't looked at the code. But giving you the benefit of the doubt, please post how someone can override php code. If they are able to do that, then much of the Internet is broken.

You are confusing Honeypot concepts with this addon. They are very different.

OK. When you have the details I mentioned please post them here and I will take a look.

As mentioned in the instructions, please post the details of an account that was created along with your HP settings. Otherwise, I am just blindly guessing. I don't understand what you mean by this since the release version of HP doesn't have an option to block IP's. You have to do that manually.

They should never get past this point, assuming you have the telephone and/or fax fields showing. The Honey Pot code checks for letters in those fields and will stop the creation if found. Also, be sure you have the option to create account check option enable or all other account checks will be ignored.

I see the code in my shop but not in the package. I must have forgot to include it or deleted in an earlier version. I do apologize for the mistake. To fix it, edit the googlesitemap/index.php file and find this line: include_once('includes/application_top.php'); and add this below it: if (! empty(GOOGLE_XML_SITEMAP_SECURE_IP)) { $safe_ips = explode(',', GOOGLE_XML_SITEMAP_SECURE_IP); if (! in_array($_SERVER['REMOTE_ADDR'], $safe_ips)) { header("location:http:127.0.0.1"); } }

You could use the Secure IP option in the settings.

I'm hearing this more and more. The main problem you will have is with the database conversion, if you need to keep your current customers, orders and products. Once the database is working, then you just need to make sure whatever options you have in your Magento shop are in the oscommerce one. There won't be direct replacements but you should be able to find something close, though some older addons will need to be converted. As for the oscommerce shop, be sure to use the Phoenix version of you will waste a lot of time.

@tonymazzBe sure to apply the fix to the captcha.php file mention on the last page or two.

I'll rewrite the code in the next version. For now, if it causes problems then don't use it for that page.

It isn't defined. I will fix it in the next version. For now, just replace MODULE_HEADER_TAGS_HONEYPOT_CREATE_ACCOUNT_SECURITY_FAILURE with 'some text here' Be sure to use the apostrophes as shown.

That definition was added in the Frozen version. If you are using an older version of oscommerce, it probably should be removed from the honeypot code. In the display module, find this tep_draw_input_field("security_check", NULL, "required aria-required=\"true\" id=\"captchaAnswer\"") . FORM_REQUIRED_INPUT . ' and change to tep_draw_input_field("security_check", NULL, "required aria-required=\"true\" id=\"captchaAnswer\"") . '

The intention of the honeypot_verify_contact_us.php was meant to be a catch-all for all of the pages except create account. But I didn't revisit that code in this version since I was concentrating on the create account changes. Looking at it now, I can see some changes are needed but I think it will work. I checked the file you mentioned but don't see the code you mentioned. In general, any page that submits a form will have a line like this if ($error == false) { There may be multiple lines like that. The verify line of Honeypot should go right above the one before the code that accepts the input . Include the verify contact us file should work but any failures will report it is the contact us page where they occurred. That is not a problem with the code but can be confusing. For all such form pages, be sure to put the display line right above the submit button code and to check the page in the Honeypot settings. Please give it a try and let me know if it doesn't work.

No needed at all. I would rather have the suggests than not have them.