Add inputfieldCaptcha

[*Most Powerful Pony!*]

I'm use inputfieldForm module for custom form at front-end on my project and except CFRS there is necessary an input Captcha, it would be healthy if it is available in modules by default!

[ryan]

The consensus around here has been that captcha is not worthwhile. Most of us get better results by using honeypots, which are simpler both for the user and the developer. However, if you or anyone else decides to build a Captcha Inputfield I'm here to support and answer any questions you have, and I'm sure there will be an audience for it in the modules directory. But if your goal is to prevent spam submissions, definitely look into using a honeypot first, as your users will thank you and you'll likely see less spam too. 

[*Most Powerful Pony!*]

Decided for myself that it is possible to use the property pattern, because after the $ form-> processInput ($ this-> input-> post), if not match, an error will be. Correct if I'm wrong.

[pine3ree]

Hello @*Most Powerful Pony!*,

implementing a captcha field is quite simple in PW.

A captcha field basically needs to validate against a randomly generated value stored in a session. The value changes on every new captcha image generation.

1) for the matching part you can extend InputfieldText (in the same way InputfieldEmail is built) to add a string match validator, but i wouldn't bother. I use a std InputfieldText and check the value when processing the form against a session value.

2) Image / security code generation generation

there are so many opensource classes you can use: 

- http://code.google.com/p/cool-php-captcha/

- https://github.com/Gregwar/Captcha

- https://code.google.com/p/euphoric-form/source/browse/spam.php

to name a few and simple to use examples

what you need to do is create a new file (my-captcha-generator-file.php) which serves as image generator (it will output the raw image).

In this file you include the file of your preferred captcha generator class and add a line (before the image output) to store the newly generated security code 

$session->captcha_code = $myCaptchaClassInstance->getTheCode();
// usually captcha generators have a method to get the generated code

Now the image is sent to the browser through an img tag whose src url needs to be create by us.

Basically:

<img id="captcha-image" src="{image-generator-url-here}">

the {image-generator-url-here} must be  a service that just return the raw image.

We already have the file who outputs the raw image.

To make it do that through a url I use this simple method:

suppose we are building a contact form in a contact-page whose url is "/contact"

!!The "contact-page" template need to have urlSegments enabled!!

I will use the url /contact/captcha as the captcha generator service url

in your  "contact-page.php" template file check for the first segment

$action = $sanitizer->name($input->urlSegment(0));
if ($action === 'captcha') {
    include 'my-captcha-generator-file.php'; // this output the raw image
    exit;// output the raw image and exit
} 

 so that your img src can be written as:

<img id="captcha-image" src="<?php echo rtrim($page->url, '/'); ?>/captcha" alt="">

now you just need to process the form and check the captcha field value against $session->captcha_code

Last considerations:

if you want the url /contact/captcha not to be public, just check for $config->ajax and use an empty img src (or better a placeholder image)

<img id="captcha-image" src="{placeholder}" alt="">

and change the source on $(document).ready(...) using a javascript ajax call.

To regenerate the captcha w/o page reload using a button  with html id="action-refresh-captcha":

jQuery(function($) {
    $('#action-refresh-captcha').on('click', function(e) {
        var ms = (new Date()).getTime();
        var src= '<?php echo rtrim($page->url, '/'); ?>/captcha?t=' + ms;
        $('#captcha-image').attr('src', src);
        e.preventDefault();
    });
});

we just add a timestamp to force the browser to refresh the image src, in other words "Touching" again the captcha generator url by changing the img src html attribute will create a new security code stored in the session and the relative raw image.

[adrian]

Might be simple, but just because you can doesn't mean you should

[cstevensjr]

I do a lot of form based websites/applications.  Since I started using ProcessWire, I haven't had a need to deal with unreliable Captcha schemes and haven't had to deal with spam.  As Ryan stated, using honeypots is a preferable option.

[pine3ree]

Well, respectfully, i don't agree. Let me explain why.

A common contact form consists usually of 4-5 fields. Add a honeypot field. That makes 5-6.

An intelligent (does it exists) bot will just need to send 5-6 submissions each 1 with a different empty field to override the honeypot protection. I think we are expecting spambots doing that very soon as a rule.

But the problem is if someone targets your forms. Sending automatic annoying (but valid) requests with an empty honeypot field is easy to do.

If the contact form send an email to the site owner and possibly 1 to the requester if a mandtory contact email field exists we'll have 2 mail messages per fake request.

And consider the consequences on mail servers and spam ip blockers.

So I've always felt safer having also a little captcha telling humans apart. It doesn't need to be recaptchas...1-2 years ago it was almost impossible to get them right at the first try. While working with php/perl, I had been administrator of mail/web/db freebsd server for more than 10 years. When I had problems with spam, 80% of the times it originated from web hosts...so better stop the issue as soon as possible in the chain.

Also the problem is not related to pw or this/that cmf/cms or even php. it exists whenever a form submission involves sensitive operations on the server side.

kindly

[cstevensjr]

It's a serious issue, however the truth is that there is no single right answer/solution that is assured to keep all form submissions safe.

Furthermore, You are entitled to your own opinion and actually it won't hurt anything for ProcessWire users to have an additional choice/option to fight spam. 

[pine3ree]

I completely agree, there is no standard safe way to protect form handlers from faked submission requests. So it's good to hear different opinions and have different solutions to choose from. Sharing experiences (good and bad) makes everyone better.

As for me, in the last 6 months i moved from difficult captchas to a combination of simpler captchas + a hp field.

kind regards 

[Soma]

My and PW honeypots are reversed.

There's no field in html source. The hidden field get's added via javascript, and if the field isn't submitted it is counted as spam.

I only got troubles when I used captchas years ago. I'm using honeypots since 2-3 years now and never recieved any spam (apart from the 1-2 manual ones).

[pine3ree]

This is the hp solution that i prefer using.

To be more safe the autofilled value should be related to the session, like a javascript enabled csrf field. Otherwise if the value is constant, and someone wants to target the form it will just be a matter of adding a field with a predefined value (in this case just not empty).

[LostKobrakai]

@ Soma

How do you think about the few people who indeed disable js on their side?

[Soma]

Depends. I don't care about them. They most likely will have many other troubles anyway these days.

If you care about them add a noscript tag with a message. Or use the normal honeypot method.

[pine3ree]

Hello LostKobrakai,

i think this is an old objection, i mean it could be a valid one back in 2004~2005.

Nowadays, I cannot think about websites working w/o javascript. When i started developing for the web i initially was against js dependency, but today we build entire apps relying on js. TV menus are built using js frameworks.

So i think everyone can assume javascript is always enabled, and if it's not you add a noscript warning message close to the header.

kindly 

[LostKobrakai]

To quote a earlier entry here:

[…], but just because you can doesn't mean you should

That's my opinion on js dependency and I try to build my websites as accessible as I can. I find it quite sad, that most of the time even big agencies don't even care about a text only fallback for their fancy new parallax whatever websites, while at the same time lots of webdevelopers fight for a more accessable web.

[Soma]

JS is accessible.

[LostKobrakai]

But working without js is still more accessable as it just works everywhere and I think it's not to complicated for smaller webseites without thousands of pages, to have them working even without js, at least for basic forms an such things. Not every website can do that, but if I see a parallax webpage which essentially only holds text, images and videos, which where heavily composed with js animation and parallax effekts, I do wonder, why they can't manage to present just the content in a simple structured way, if js is disabled.

[Martijn Geerts]

The last years Javascript has become necessary in a lot of big websites. Without Javascript, YouTube & Facebook etc. won't function. We as developer can benefit from this trend. It's rare that the average guest turns Javascript off and if they did they know.  With forms I hide the forms with CSS, and show it again with Javascript. If javascript is disabled, you can show it with the <noscript> tag. Captcha brings IMOH inaccessibility to the blind or people with low vision. Even for me, with perfect eye sight I have trouble to decipher them. 

Not every website can do that, but if I see a parallax webpage which essentially only holds text, images and videos, which where heavily composed with js animation and parallax effekts, I do wonder, why they can't manage to present just the content in a simple structured way, if js is disabled.

The reason I see is that the purpose of those websites is not to serve out information. But the main reason is marketing. Eye catching is for those companies more valuable. Do those companies even know what accessible web is or do the care enough to pay for it? Then you have those sites where developers think in front-end templates and not in structure. If you see the tabs in Bootstrap, they won't function without javascript. I think that's a sad thing. With good and structured HTML you could make tabs work with some simple :hover functionality in CSS.