Jump to content

Recommended Posts

3 hours ago, Jack_mcs said:

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.

Any checking that worked in 1.0.5.3 will work in 1.0.5.4.  All 1.0.5.4 did was provide an easier way to block failures.  So if it won't work in 1.0.5.4, it won't work in 1.0.5.1 through 1.0.5.3 either.  To make something that would work with the change from 1.0.5.4 work in 1.0.5.1 through 1.0.5.3, someone could add the tep_block_form_processing function from 1.0.5.5 (the one from 1.0.5.4 had a typo for create_account).  Or just duplicate the functionality of that function. 

I would say that the correct way to implement form verification in 1.0.5.1 or later would be to write replacement customer_data modules.  But that's another conversation.  My point here is that it is extremely unlikely that something that doesn't work in 1.0.5.4 will work in 1.0.5.1 through 1.0.5.3. 


Always back up before making changes.

Share this post


Link to post
Share on other sites
3 hours ago, ecartz said:

Any checking that worked in 1.0.5.3 will work in 1.0.5.4. 

The previous versions of Phoenix used the $error variable to allow an account to be created or not. The code in Honey Pot relies on that variable. So maybe using the function you mentioned will work. As mentioned, I haven't had time to go though that. But even if it does, the addon would still fail with 1.0.5.4 because the HP code checks the variables by name, like $postcode. Those are now in the customer details code so the HP code can't work as it is.

Share this post


Link to post
Share on other sites
On 3/19/2020 at 6:51 PM, Jack_mcs said:

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

@Jack_mcs These two settings do not work in my live 1.0.5.0 shop nor in my test 1.0.5.0 on a local LAMP server.

As both these shops have some add-ons installed,  I have just set up a third, fresh 1.0.5.0 installation but it still doesn't work so I don't think it's a setup thing as I have made no changes in the default installations.

I set the "Verify Postal Code" to "Blank" but it doesn't block creating a new customer account with "asdfg" inserted in the "Post Code" field of the registration form.

Then I set the "Verify Postal Code" to "Both" and I am still able to create a new account with "asdfg" in the "Post Code" field.

Maybe this IS the expected behaviour? If so, how is it different from "Ignore"? If not, what is their expected behaviour?

How did you test these setting in your 1.0.5.0 test installation?

 

btw. I have this add-on installed in my live shop anyway (with the "Verify Postal Code" set to "Numbers") and it does an incredible job as only 2 (two) emails with URL's managed to pass through during a week, and 137 attempts to send a message or create an account were blocked (mainly due to filling out the hidden field which was the original idea of the Honey Pot trap). This is simply amazing!

Share this post


Link to post
Share on other sites

@PedrosI'm sorry but I don't have an answer for you. The code works fine for me. The only way I could resolve your problem would be to troubleshoot it. So unless the problem shows up for me, this will have to remain a mystery.

Share this post


Link to post
Share on other sites

Set the setting to numbers and enter in a postal code that is all letters. The account should not be created.

Share this post


Link to post
Share on other sites

@Jack_mcs Yep, the "Numbers" setting works perfectly. I never said it didn't.

What seems not to work are the other two settings, i.e. "Blank" and "Both". Can you test these with an all-letter postal code?

Share this post


Link to post
Share on other sites

Please replace the CheckPostalCode function with the one below and try again:

function CheckPostalCode($postcode, $country) {
    if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_POSTAL_CODE != 'Ignore') {

        if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_POSTAL_CODE == 'Blank' || MODULE_HEADER_TAGS_HONEYPOT_VERIFY_POSTAL_CODE == 'Both') {
            if (empty($postcode)) return false; //post code is blank and the options say to allow this
        } 
        
        if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_POSTAL_CODE == 'Numbers' || MODULE_HEADER_TAGS_HONEYPOT_VERIFY_POSTAL_CODE == 'Both') {
            $has_numbers = false;
            for ($i = 0; $i < strlen($postcode); ++$i) {
                if (ctype_digit($postcode[$i])) {
                    $has_numbers = true; 
                }    
            }    
            if (! $has_numbers) return true;
        }         
 
        if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_POSTAL_CODE == 'Numbers') {
            if (empty($postcode)) return true; //post code doesn't contain a number so fail
           
            $ZIPREG=array(
             "US"=>"^\d{5}([\-]?\d{4})?$",
             "GB"=>"^(GIR|[A-Z]\d[A-Z\d]??|[A-Z]{2}\d[A-Z\d]??)[ ]??(\d[A-Z]{2})$",
             "DE"=>"\b((?:0[1-46-9]\d{3})|(?:[1-357-9]\d{4})|(?:[4][0-24-9]\d{3})|(?:[6][013-9]\d{3}))\b",
             "CA"=>"^([ABCEGHJKLMNPRSTVXY]\d[ABCEGHJKLMNPRSTVWXYZ])\ {0,1}(\d[ABCEGHJKLMNPRSTVWXYZ]\d)$",
             "FR"=>"^(F-)?((2[A|B])|[0-9]{2})[0-9]{3}$",
             "IT"=>"^(V-|I-)?[0-9]{5}$",
             "AU"=>"^(0[289][0-9]{2})|([1345689][0-9]{3})|(2[0-8][0-9]{2})|(290[0-9])|(291[0-4])|(7[0-4][0-9]{2})|(7[8-9][0-9]{2})$",
             "NL"=>"^[1-9][0-9]{3}\s?([a-zA-Z]{2})?$",
             "ES"=>"^([1-9]{2}|[0-9][1-9]|[1-9][0-9])[0-9]{3}$",
             "DK"=>"^([D-d][K-k])?( |-)?[1-9]{1}[0-9]{3}$",
             "SE"=>"^(s-|S-){0,1}[0-9]{3}\s?[0-9]{2}$",
             "BE"=>"^[1-9]{1}[0-9]{3}$"
            );
            $db_query = tep_db_query("select countries_iso_code_2 from countries where countries_id = '" . tep_db_input($country) . "'");
            if (tep_db_num_rows($db_query)) {
                $db = tep_db_fetch_array($db_query);
                if (!preg_match("/".$ZIPREG[$db['countries_iso_code_2']]."/i",$postcode)) {
                    return true;             
                }  
            }
        }  
    }
    return false;    
}

 

Share this post


Link to post
Share on other sites

@Jack_mcs Thanks for the suggestion. I have just tested this modified code but it only seems to have solved part of the issue.

I set the "Verify Postal Code" to "Both" and it didn't allow me to pass with "asdfg" in the "Post Code" field of the registration form, which is the expected behaviour, I suppose.

It doesn't seem to check the country-code array, though, as I was still able to create an account with an invalid postal code, i.e. entering "45jkj45" for Spain (ES) that only allows 5-digit all-number codes.

It gets blocked with the "Verify Postal Code" set to "Numbers" but not with "Both".

Also, setting the "Verify Postal Code" to "Blank" hasn't changed its behaviour and still lets a user create an account no matter what they enter in the Post Code field of the registration form, be it letters, numbers or a combination of both.

Share this post


Link to post
Share on other sites

I don't see why the code for Spain is failing. I will have to test it.

Setting it to blank means to allow any code through.

Unfortunately, I don't have the time to work on this anymore at the moment. If it isn't helping you to have the post code check enabled, I suggest turning that option off until it is fixed.

Share this post


Link to post
Share on other sites

OK, this explains some behaviour. I thought that setting "Verify Postal Code" to "Blank" only allows empty post code field in the registration field.

If it allows any code, how is it different from "Ignore"? If it's not any different, why not just remove it (together with "Both")?

Anyway, as I said before, I have this add-on installed and set to "Numbers" in my live shop and it works like a charm, letting virtually no spammer pass, which makes it one of the most useful contributions ever created for osCommerce.

Thanks!

Share this post


Link to post
Share on other sites

I can't get this to work. At all. I have all of the settings turned off, so the module should be as open as possible. When I create an account and click Continue, I just get an empty page of 0 bytes. And the new customer does not get added.

The error log shows this:
[15-Apr-2020 14:34:34 America/Chicago] PHP Parse error:  syntax error, unexpected ')', expecting :: (T_PAAMAYIM_NEKUDOTAYIM) in /home/mrwnhcom/public_html/includes/functions/honeypot.php on line 261

Any idea what might be wrong? Thank you so much for helping!

Share this post


Link to post
Share on other sites

I did notice one of the code replacements did not match exactly. This instruction:

-----------------

FIND:

<?php echo tep_draw_form('create_account', tep_href_link('create_account.php', '', 'SSL'), 'post', '', true) . tep_draw_hidden_field('action', 'process'); ?>

REPLACE WITH:

<?php //BOC Honeypot ?>
<?php echo tep_draw_form('create_account', tep_href_link('create_account.php', '', 'SSL'), 'post', 'class="form-horizontal" onSubmit="return validateMyForm(create_account);"', true) . tep_draw_hidden_field('action', 'process'); ?>
<?php //EOC Honeypot ?>

-------------

My original code looked like this:

<?php echo tep_draw_form('create_account', tep_href_link(FILENAME_CREATE_ACCOUNT, '', 'SSL'), 'post', 'onsubmit="return check_form(create_account);"', true) . tep_draw_hidden_field('action', 'process'); ?>


Might that be the problem?

The ONLY file I am trying to use this honeypot captcha for is create_account.php.

Thank you.

 

Share this post


Link to post
Share on other sites

Without knowing the version of your shop, it would be a waste of time to try to answer. Please always include the version of oscommerce you are using, for any question in these forums.

Share this post


Link to post
Share on other sites

I'm so sorry. Version 2.3.4.1, just installed this week to test some new apps including this one.

Out of the box coding in create_account.php line 271 in OSC 2.3.4.1 is:

<?php echo tep_draw_form('create_account', tep_href_link(FILENAME_CREATE_ACCOUNT, '', 'SSL'), 'post', 'onsubmit="return check_form(create_account);"', true) . tep_draw_hidden_field('action', 'process'); ?>

HoneyPot instructions are below, which omits the instruction I have highlighted above in bold.

FIND:

<?php echo tep_draw_form('create_account', tep_href_link('create_account.php', '', 'SSL'), 'post', '', true) . tep_draw_hidden_field('action', 'process'); ?>

REPLACE WITH:

<?php //BOC Honeypot ?>
<?php echo tep_draw_form('create_account', tep_href_link('create_account.php', '', 'SSL'), 'post', 'class="form-horizontal" onSubmit="return validateMyForm(create_account);"', true) . tep_draw_hidden_field('action', 'process'); ?>
<?php //EOC Honeypot ?>

When I submit create_account.php, I get a blank page, and the database is not updated.

 

Share this post


Link to post
Share on other sites

All that line changes is the name of the function to call. You can replace the entire line and it should be fine or just replace the words check_form with validateMyForm.

But if the create account page loads initially, which it sounds like it does, that change would not cause the problem. Have you installed the module in admin? Also, you don't mention the other changes needed for that file so I suspect you might be using the wrong version for the installation. You should be using the instruction file named Install_Frozen_V234.txt.

Also, and more importantly, since this is a new installation of oscommerce, you should not be using the version you are using. Scroll down on the Products page and download the Phoenix package. The one you are using is very outdated and has a numbers of problems.

Share this post


Link to post
Share on other sites

A new version has been uploaded with these changes:

  • Added the time to submit code to the form checker (non-create account) code.
  • Added files, new and changed, for pre-2.3 shops.
  • Added code to remove a blocked IP from the .htaccess file.
  • Added 144 countries to the postal code check.
  • Added an icon to the left column for Phoenix versions.
  • Changed the code for the CheckCountryState function to ignore countries without states.
  • Changed the code for the CheckPostalCode function to better handle the various options.
  • Changed the code for the captcha font to use the full path since it failed on some servers.  
  • Changed code to be compatible with all versions of Phoenix.
  • Fixed code for country-state check that caused it to always be active.
  • Fixed the time to submit function to work correctly. Found by @dfr717.
  • Fixed the postal code checking due to problems found by @pedros.
  • Fixed the hidden field test so that it works correctly.
  • Fixed code to prevent failures for some multi-named databases.

Changes made but not in this version:

  • Added the date created to the Account Check page in admin.
  • Added an option to clear the log file in admin.
  • Added an option to display the log for just the current month.
  • Added an option to skip logging first-time accounts.
  • Changed the order of the log file to show latest entries first.
  • Changed the filtering for names in admin to be give better and faster results.
  • Changed the code that prevents url's to check for url's without schemes, like example.com.

Share this post


Link to post
Share on other sites

Jack installed new version to get rid of this warning. But even the new version error is showing up. using V 234 php 7.2

warning. PHP Warning:  Use of undefined constant ENTRY_ENQUIRY_TEXT - assumed 'ENTRY_ENQUIRY_TEXT' (this will throw an Error in a future version of PHP) catalog/contact_us.php on line 117

Here is line 117 in contact us

 echo tep_draw_textarea_field('enquiry', 'soft', 50, 15, NULL, 'required aria-required="true" id="inputEnquiry" placeholder="' . ENTRY_ENQUIRY_TEXT . '"');

attached is the contact_us.php file

Thanks Nick

 

contact_us.php


"Do what I'm thinking Not what I said." https:windowanddoorparts.us

Share this post


Link to post
Share on other sites

That's not anything to do with this addon. 2.3.4 isn't designed to work with 7.2. It would probably cause failures with just 7.0. You will find many others if you look for them.

Share this post


Link to post
Share on other sites

That's really interesting been updating php when they came available from GoDaddy. Changed my php ver to 7.0 and getting no errors at this time. Seems like everything is working.

Thanks Nick


"Do what I'm thinking Not what I said." https:windowanddoorparts.us

Share this post


Link to post
Share on other sites

Hello, 

I have installed the honey pot app on 2.3.4 Gold, I think correctly but when I set the options and then save them I get the following page:

Forbidden

You don't have permission to access this resource.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

 

I'm sure I'm missing something obvious but I could really do with some help, please.

Andy

Share this post


Link to post
Share on other sites

Are you saying as soon as you enable the Honey Pot module you cannot reach the admin, your shop or both? What do you do to not be blocked or are you still locked out? 

Share this post


Link to post
Share on other sites

Thanks for replying. I was just checking to see if it did lock me out of the shop, the problem doesn't happen now, I spoke to my site host last night and was told it was a security problem that I would have to solve. I can only assume they changed something later.

Thanks for your help, I will wait and see if it works properly for me.

Regards Andy

Share this post


Link to post
Share on other sites

Quick question on the file \catalog\includes\languages\english\honeypot.php.  Are the text constants contained in the honeypot.php file displayed to the user or only to the administrator?  If they are displayed to the user/customer does this contribution support multiple languages defined in the osCommerce shop?  Thank you.

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

×