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

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

×