non-CAPTCHA and Honey-pots

[swguy]

I'd be happy to do the changes I suggested - just let me know.

[davewest]

I'd be happy to do the changes I suggested - just let me know.

Please do. With IE going down a different path with HTML5 and not reading the response from the slider the same as Mozilla the script needs help. I don't have any MS OS any more for VM, used the disks to scare away the birds. I can't test the script.

[OldNGrey]

I have made non-CAPTCHA and Honey-pots work for IE v10 and IE v11 on zc156a. The slider is a bit ugly but functions. I need to put up a notice for IE users to upgrade to something else as IE 11 supports ends this year.

non-CAPTCHA and Honey-pots is currently in my dev env on 157a and it works. I only use non-CAPTCHA and Honey-pots for creating accounts and contact-us pages.

I can post my changes if they might be of use.
Attachment 19282 Initial slide in IE 11
Attachment 19284 Button pressed and value changed in IE 11

- - - - -
environment Dev: Zen Cart 157a; Apache 2.4.46; PHP 7.4.9; MySQL 5.7.31; Windows 10

[davewest]

I have made non-CAPTCHA and Honey-pots work for IE v10 and IE v11 on zc156a. The slider is a bit ugly but functions. I need to put up a notice for IE users to upgrade to something else as IE 11 supports ends this year.

non-CAPTCHA and Honey-pots is currently in my dev env on 157a and it works. I only use non-CAPTCHA and Honey-pots for creating accounts and contact-us pages.

I can post my changes if they might be of use.
Attachment 19282 Initial slide in IE 11
Attachment 19284 Button pressed and value changed in IE 11

- - - - -
environment Dev: Zen Cart 157a; Apache 2.4.46; PHP 7.4.9; MySQL 5.7.31; Windows 10

CAPTCHA is built into ZC157x and has no need for any CAPTCHA add-ons... eye testing nor honey.. so all you're adding is frustration to your customers..

Allot of users refuse to upgrade to a HTML5 enabled browser. All they see of the slider is a text input field.

Post your script. Does it work on FF too?

[OldNGrey]

The slider displays in FF, Chrome, Edge and IE 11 & 10.

<script type="text/javascript">
$(document).ready(function () {
  
var slideCol = document.getElementById("id1");
var y = document.getElementById("f");

y.innerHTML = slideCol.value; // Display the default slider value
slideCol.onchange = displayCol;
// Update the current slider value (each time you drag the slider handle)
slideCol.oninput = displayCol;
function displayCol() {
    y.innerHTML = this.value;
	    if (this.value == "<?php echo SPAM_TEST; ?>") {
      y.innerHTML = "<?php echo SPAM_ANSWER; ?>";
    }     
	}
});

</script>

[davewest]

The slider displays in FF, Chrome, Edge and IE 11 & 10.

So basically you named the function and then hit both the onchange and oninput events... It works, most of the responses are at a micro second... based on focus or order. The input event comes before the corresponding change event if any... However, I beleave all but IE respond to both onchange and oninput. IE response is to the onchange event. So you could just use the onchange event, but that leads to other problems with other browsers.

For example, this is from an article in Mozilla..

The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus.

As shown in the quote above, onchange should always fire after oninput, so the fact that Firefox waits for the range slider to lose focus before firing the event (for both mouse and keyboard) seems to be the correct behaviour. Chrome does not wait until the control is unfocused when using the keyboard, but it does so with the mouse.

IE11, of course, is completely wrong on two counts: It doesn’t recognize oninput when applied to a range slider and it responds to onchange as if it was oninput, firing the event immediately instead of waiting until the slider stops moving or loses focus.

Maybe a suggestion such as below; This would not support IE8 and below, but only IE9 and above are HTML5 browsers.

$(document).ready(function () {
  
var slideCol = document.getElementById("id1");
var y = document.getElementById("f");

var ie = 'ActiveXObject' in window;

y.innerHTML = slideCol.value; // Display the default slider value

if (ie) {
slideCol.onchange = displayCol;  // Update slider value (IE)
} else {
slideCol.oninput = displayCol;  // Update slider value (Mozilla)
}

function displayCol() {
    y.innerHTML = this.value;
        if (this.value == "20") {
      y.innerHTML = "Humen";
    }     
    }
});

[Lance Turner]

Just wanted to say thanks for this plugin, store got hit with a pretty clever script that created accounts, placed items in the cart and then checked out via eway, had over 1000 attempted transactions in a couple of hours. Added this and all stopped, is a great temp fix until I get time to upgrade to 1.5.7c.

[tj1]

I'm using Zen Cart 1.5.7d and the built in spam prevention doesn't seem to be working. I'm still getting a lot of spam messages through the contact us page.
Is there some setting or code that needs to be changed to make it work?

[dbltoe]

The question is... What files on your site are different from a standard 1.5.7d install.

What template are you using? A store-bought template might not have the proper code imbedded in their files.

[tj1]

I'm using the default responsive classic template, no changes to the contact us template file.

Actually, it seems to be working as intended. I did some testing by making the hidden field visible and then sending some messages putting something in the antispam field and other times leaving it empty. I did not get any of the messages when I put something in the antispam field.

So it seems the bots just somehow figured it out.

Can someone suggest any change to the code to fool the bots and make it work?