Jump to content

Recommended Posts

45 minutes ago, Chadduck said:

Since that solved the NO EMAIL issue what do I need to do to STOP emails that are for valid accounts? 

That was an option in a previous version but it was removed when the file log was added. If you remove this line, it will stop those entries:

WriteToLog(sprintf(TEXT_CREATE_ACCOUNT_NEW_ACCOUNT, $cust)); 

 

47 minutes ago, Chadduck said:

be changed in any manner to indicate what the violations were? 

The $text in that line is sending the same entry that you see in the log file. That explains what the failure was. Are you not seeing that?

Share this post


Link to post
Share on other sites
20 minutes ago, Jack_mcs said:

The $text in that line is sending the same entry that you see in the log file. That explains what the failure was. Are you not seeing that?

Sorry about that - I missed it.  Yes it is showing in BOTH I was so focused on getting the email - and when the emails happened - Well excitement took over.  This upgrade process has been 6 months in the making and making sure things are working with emails, credit cards, etc. - I was excited when I started getting the HoneyPot emails since I thought I had coded something which immediately made me start questioning IF I had miscoded it had I done the same elsewhere.

I have told you privately but I will do so here in public 

Thanks again for all that you give to the community as a whole and especially the help you have provided to me.

BJ

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

This is such a wonderful contribution.  It is an invaluable security tool for every store.

Having said that - I decided after a week of having my new store operational to enable the captcha portion.  Up to this point I have had this setting set to None

Show Captcha
Do you want to display a security challenge on the page?

 Numbers
 Image
 None

FIRST I tried Numbers - No Joy.
I then tried Image - No Joy.

For some stupid reason I can NOT get the captcha question (numbers or image) to show.  I do get the the line showing "Security Question" then a space where the captcha should be and finally the text entry for the answer.  

Reviewing the php_error.log there are these entries. the ....../ indicates the long directory on the server

PHP Warning:  imagettfbbox(): Could not find/open font in ....../captcha.php on line 44
PHP Warning:  imagettftext(): Could not find/open font in ....../captcha.php on line 89

As pointed out earlier in this topic - GD Support is enabled.

The verdana.ttf is located in the same directory as captcha.php

What should I be looking at or looking for.

Share this post


Link to post
Share on other sites
7 hours ago, Chadduck said:

The verdana.ttf is located in the same directory as captcha.php

What should I be looking at or looking for.

Try changing this line in the captcha.php file

$font = 'verdana.ttf';

to this

$font = realpath('verdana.ttf');

 

Share this post


Link to post
Share on other sites
10 hours ago, Jack_mcs said:

Try changing this line in the captcha.php file


$font = 'verdana.ttf';

to this


$font = realpath('verdana.ttf');

 

THAT TOOK CARE OF IT...

Again - I am indebted to you.

THANK YOU

BJ

Share this post


Link to post
Share on other sites

Hey Jack / ecartz / Brockley John

I have found and fixed all of my problems thanks a load for all of the help. I started by reinstalling clean 1.0.4.0 with a new database and installing all languages and HoneyPot and configuring the same as my live 1.0.4.0 store. HoneyPot worked properly and all other errors from the log were gone, except one from the espanol module (I have already informed Raiwa of the issue and hopefully the fix there).

I then connected the new install to the old database and the errors returned; but HoneyPot was still fine. So the PHP errors were linked to the database but the HP errors were software.

So back to the live install. First I found that I had coding from earlier version of HoneyPot in both contact_us.php and create_account.php having fixed that I still had the errors. Then I decided to uninstall HP and reinstall, this is when I noticed that I had copied the HP admin files to the catalog root. After uninstalling, including the incorrectly unloaded files and reinstalling the HP (to the correct directories LOL). I re-enabled HP and all is working great.

So ecartz hit the nail on the head the main problem was files uploaded to the wrong place. I was running 1.9 in the store front and 1.8 in the admin kind of.

Brockley John helped with the PHP errors with a remove the manufacturer's box and reinstall.

Everything is now functioning and no more errors in the error report.

Thanks to all for the aid.

Ron

Share this post


Link to post
Share on other sites
Posted (edited)

Jack

As previously discussed in Honeypot I had set Block IP Automatically to 4. After the following incident I put it back to the original setting - blank.

Last evening I had a lady that was having difficulty creating an account.  Ultimately got herself, or I should say her IP, banned.  She emailed me and identified herself and asked IF I could help.  Being late I told her to send me a phone number to contact her.  She did.  I will manually take her order over the phone.

Anyway - this morning, I tried to create a generic account for her BUT was unable to do so.  Prior to doing so, I manually removed her IP from the Honeypot log.  

HER IP from Honeypot (manually removed)

XXX.YYY.ZZZ.209 01-07-2020: Denied due to captchaThis IP has 1 violations.
XXX.YYY.ZZZ.209 01-07-2020: Denied due to being too soon by GENNA ______ .This IP has 2 violations.
XXX.YYY.ZZZ.209 01-07-2020: Denied due to captchaThis IP has 3 violations.
XXX.YYY.ZZZ.209 01-07-2020: Denied due to being too soon by genna ______ .This IP has 4 violations.
XXX.YYY.ZZZ.209 01-07-2020: Permanently blocked from the site due to too many violations.This IP has 5 violations.
XXX.YYY.ZZZ.209 01-07-2020: Permanently blocked from the site due to too many violations.This IP has 6 violations.
XXX.YYY.ZZZ.209 01-07-2020: Permanently blocked from the site due to too many violations.This IP has 7 violations.
XXX.YYY.ZZZ.209 01-07-2020: Permanently blocked from the site due to too many violations.This IP has 8 violations.

After REMOVAL when I attempted to create the account I received the following

MY IP
XXX.YYY.ZZZ.15 01-08-2020: Denied due to count limit by Genna ______ .This IP has 3 violations.

2 of the violations were for the password being too short. DOH!!!

HOW DO I REMOVE her name, IP from the Honeypot and/or View Counter ban?

I have done the following

1. searched the database - her name does not exist
2. searched the Honeypot log and removed the IP that she used

BJ

Edited by Chadduck

Share this post


Link to post
Share on other sites
2 hours ago, Chadduck said:

Anyway - this morning, I tried to create a generic account for her BUT was unable to do so.  Prior to doing so, I manually removed her IP from the Honeypot log.  

A blocked IP is the IP of the person, not the account. So if you are creating an account for someone, it is your IP that is checked. If you have not added your IP to the Exclude IP's setting, then you will be blocked like anyone else once you have reached any of the limits.

If her IP is being blocked by Honey Pot, you can remove the block in the Maintenance section in admin. If it is being blocked by View Counter, find the IP in the Banned List dropdown in the Monitor section and click the remove from list button.

Share this post


Link to post
Share on other sites
On 11/25/2019 at 4:01 AM, mojohost said:

@Jack_mcs

Edit: I set Create Account Check to false, and I was able to create an account no problem. I think it should be a flag to the issue that the log is telling me that it's failing the state/country check even though I have state/country check set to false. This implies a problem with the addon at this point rather than my create_account.php file. One, the state and country match and two, I have it set to false so it should be ignoring it regardless of a match or not. Honey Pot shouldn't be failing the state/country match when it's set to false.

 

On 11/25/2019 at 2:30 PM, Jack_mcs said:

I just tried it here. The country-state error didn't get logged when that setting was off and a wrong combination was mentioned.

 

On 11/25/2019 at 11:04 PM, mojohost said:

This is going to be a weird one. I think this was caused because I had previously emptied my countries table and manually added back just United States and Canada from within the admin interface. I reverted that change earlier today with a database restore (that was the only change), and now when I tried to create the account it worked without issue. So, for reference, if someone has messed with their list of countries via the database, that might potentially cause the country/state issue regardless of the setting in Honey Pot.

Well, actually it seems that the country-state setting of this add-on gets lost when it has to deal with the countries that do not have any states defined in the database.
It works correctly if the chosen country has some states defined in the zones table but makes it impossible to create an account if the user chooses a country that doesn't have any state defined, like eg. Belgium or Denmark.
In such a case it shows the "The account could not be created. Please contact us for assistance." message on the screen and registers "Denied due to a country - state mismatch.This IP has x violations." in the HoneyPot_log.
The weird thing is that it does this even when the "Verify State and Country match" option in Modules -> Header Tags -> Honey Pot is set to "False", making the whole add-on virtually unusable for those who sell in and to these countries, as users from these countries will never be able to create an account.

Sure thing, even though I'm one of such shop-owners, I'm not going to give up on installing this add-on in my live shop as I consider it to be one of the best add-ons that have ever been created for osCommerce. I respect and appreciate the tremendous amount of time and knowledge put into this project, with Jack_mcs being so helpful at the same time. Big thanks to Jack_mcs for this and many other great add-ons that he has already created and will hopefully keep on creating.

I am no programmer but I somehow managed to find a temporary "solution" that seems to completely deactivate the country-state check, letting me use this add-on in my shop and letting my customers create accounts no matter what country they are from.
In /includes/functions/honeypot.php, for function CheckCountryState I changed:

return (tep_db_num_rows($db_query) ? false : true);

to:

return (tep_db_num_rows($db_query) ? false : false);

that can also simply be:

return false;

Another option that seems to work is commenting out the whole contents of this function.

Of course this is just a temporary workaround as I suppose the query should be wrapped in some kind of an IF statement checking in the database if a given country has any states (zones) defined and deactivating the check completely if it doesn't.
Still, as I said, I'm no programmer so the proper (and professional) solution may as well be completely different.
I'm looking forward to Jack_mcs introducing it so that the "Verify State and Country match" option works 100% as supposed without any issues.

Share this post


Link to post
Share on other sites

@PedrosThank you for the kind words. They are appreciated. The country-state problem is a known one and has been fixed in the next, unreleased version. I'm not sure when that will be released but here is the fix for the country-state problem. In includes/functions/honeypot.php, find

function CheckCountryState($state, $country) {
    $db_query = tep_db_query("select 1 from zones where zone_country_id = '" . tep_db_input($country) . "' and (zone_code = '" . tep_db_input($state) . "' or zone_name = '" . tep_db_input($state) . "')");
    return (tep_db_num_rows($db_query) ? false : true);
}

and replace it with

function CheckCountryState($state, $country) {
    if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_STATE_COUNTRY_MATCH == 'True') {
        $db_query = tep_db_query("select 1 from zones where zone_country_id = '" . tep_db_input($country) . "' and (zone_code = '" . tep_db_input($state) . "' or zone_name = '" . tep_db_input($state) . "')");
        return (tep_db_num_rows($db_query) ? false : true);
    }
    return false;    
}

 

Share this post


Link to post
Share on other sites

@Jack_mcs Thanks a lot for such a quick reply and the solution!

I see that my suspicion that an IF statement will sort it out was a good guess. I should definitely learn some php...

Share this post


Link to post
Share on other sites

@Jack_mcs I have just replaced the code as you suggested and it only seems to address one of the issues I mentioned.

It allows to create an account for a customer from a country that doesn't have states (zones) defined in the database only if the "Verify State and Country match" option is set to "False". If I set it to "True", there is no way for a customer from eg. Denmark to create an account, no matter what they put in the State field in the create_account form.

You can easily see this issue yourself trying to create an account with eg. Denmark as the country (or any other country without any zones defined). You will see the "Account could not be created" message and a new "Denied due to a country - state mismatch." entry will appear in the HoneyPot_log.

I think that one more IF statement is needed in the CheckCountryState function that will check if a given country actually has any zones defined in the database and will deactivate the function if it does not.

Can you make it?

 

Share this post


Link to post
Share on other sites
function CheckCountryState($state, $country) {
    if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_STATE_COUNTRY_MATCH == 'True') {
        $has_zone_query = tep_db_query("SELECT COUNT(*) AS zone_count FROM zones WHERE zone_country_id = " . (int)$country);
        $has_zone = tep_db_fetch_array($has_zone_query);
        if (0 < $has_zone['zone_count']) {
            $db_query = tep_db_query("select 1 from zones where zone_country_id = " . (int)$country . " and (zone_code = '" . tep_db_input($state) . "' or zone_name = '" . tep_db_input($state) . "')");
            return !tep_db_num_rows($db_query);
        }
    }

    return false;    
}

 


Always back up before making changes.

Share this post


Link to post
Share on other sites
20 hours ago, Pedros said:

I think that one more IF statement is needed in the CheckCountryState function that will check if a given country actually has any zones defined in the database and will deactivate the function if it does not.

I'm sorry I missed that part of the question. The code posted by @ecartzshould do what you want.

Share this post


Link to post
Share on other sites

One more thing needs sorting out.

If I set the "Verify Postal Code" to "Blank" or "Both", it doesn't seem to have any effect whatsoever.

I mean that I can perfectly register an account even though I introduce letters, numbers or their combination in the Post Code field of the Create Account registering form.

Share this post


Link to post
Share on other sites

The code checking the postal code is, among other things, comparing what is entered against known formats for certain countries. If you are checking a country that is not in the countries being checked, the code will not fail. This page shows the countries being checked. If the country you are checking is in that list, then the code is not working for some reason. In that case, please let me know the country so I can check it.

Share this post


Link to post
Share on other sites

I've checked with a country from the list (Spain - ES) and also with a country outside it (Somalia). In both cases I was able to create an account with "asdfg" as the Postal Code when the "Verify Postal Code" was set first to "Blank" and then to "Both". This is why I said that these two settings have no effect whatsoever, i.e. they just don't seem to do anything. The only setting for this option that's actually operative is "Numbers".

Share this post


Link to post
Share on other sites

If the setting is Blank or Both and the entered post code entry is blank, then no blocking should be done. If the setting is Numbers, then if the post code entry is blank or does not contain number, it should block. Only once those tests are done is the country checked. If that is how you have it set up, then I don't have an answer for you at this point. I've installed this addon into several shops and it works as expected. And I would assume others here would say something if they are having the same problem. So it seems to be a problem in your installation or maybe some unique situation just to your site that I can't reproduce. I'm sorry I can't be more helpful.

Share this post


Link to post
Share on other sites
Posted (edited)

Hi, I am just about to make the leap to Phoenix and have installed 1.0.5.0 and have installed Honeypot as the first module and am seeing the security number or code double up as per the attached image.

Any suggestions as to what may be causing this would be great. Running PHP/7.2.12 XAMP SERVER

 

Cheers!

Honeypot.PNG

Edited by nedragdnuos

Share this post


Link to post
Share on other sites
12 hours ago, Jack_mcs said:

If the setting is Blank or Both and the entered post code entry is blank, then no blocking should be done. If the setting is Numbers, then if the post code entry is blank or does not contain number, it should block. Only once those tests are done is the country checked. If that is how you have it set up, then I don't have an answer for you at this point. I've installed this addon into several shops and it works as expected. And I would assume others here would say something if they are having the same problem. So it seems to be a problem in your installation or maybe some unique situation just to your site that I can't reproduce. I'm sorry I can't be more helpful.

@Jack_mcs This situation occurs both in my live site and also in the test installation (both are 1.0.5.0) on my local LAMP server so the problem rather seems to be in the application.

Have you checked the scenarios that I described in your installations? I mean first setting the "Verify Postal Code" to "Blank" or "Both" and then creating an account with "asdfg" introduced in the "Post Code" field? Was it blocked then?

Share this post


Link to post
Share on other sites

I don't have that version of shop setup but I tried it in an older version of Phoenix and it worked. I will install that version when I have the time and test it.

Share this post


Link to post
Share on other sites

@PedrosI tested in a 1.0.5.0 shop and it worked as expected so it is due to something in your setup.

I also tested it in 1.0.5.4 and Honey Pot will not work in that version, at least as far as create account checks are concerned since the customer handling code has changed in that version. I haven't had time to figure out how to check for failures but will eventually. Until then, this addon will only fully work with 1.0.5.3 or before.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×