Spam protection module for SilverStripe CMS
Go to file
github-actions 26936f33e4 Merge branch '3.4' into 3 2024-02-07 11:15:05 +00:00
.github/workflows MNT Use gha-dispatch-ci 2023-03-21 13:41:47 +13:00
.tx ENH Update translations 2023-03-06 18:22:09 +13:00
_config FIX Typo in userforms form field class name 2017-08-28 17:41:04 +12:00
code FIX Check value is not NULL 2023-01-17 08:30:17 +13:00
images BUGFIX: Fixed replaced deprecated FieldSet() with FieldList() 2012-07-06 19:59:57 -03:00
lang TLN Update translations (#111) 2024-02-07 16:12:33 +13:00
tests MNT Explicitly test with default_spam_protector set to null 2023-01-24 10:34:16 +13:00
.editorconfig Added standard editor config 2015-11-19 13:23:15 +13:00
.gitattributes Update usage examples in readme, minor fixes in travis configuration and gitattributes 2017-08-28 13:19:05 +12:00
.gitignore Ignore .DS_Store 2014-02-10 20:48:53 +13:00
.upgrade.yml Add upgrader mapping file 2017-08-28 13:20:19 +12:00
README.md MNT Standardise modules 2022-08-01 16:23:11 +12:00
changelog.md Update changelog for 2.0.4 release 2016-05-19 11:56:38 +12:00
code-of-conduct.md Added standard code of conduct 2015-11-21 20:11:25 +13:00
codecov.yml Update Travis configuration to be standalone, add codecov.io, update license year 2017-08-28 13:11:49 +12:00
composer.json MNT Revert erroneous dependency changes (#95) 2023-03-28 17:02:59 +13:00
legacy.yml Add legacy mapping 2018-09-19 21:01:36 +12:00
license.md Update Travis configuration to be standalone, add codecov.io, update license year 2017-08-28 13:11:49 +12:00
phpcs.xml.dist MNT Use shared travis config, use sminnee/phpunit 2020-11-10 14:03:59 +13:00
phpunit.xml.dist MNT Standardise modules 2022-08-01 16:23:11 +12:00

README.md

SpamProtection Module

CI Silverstripe supported module

Maintainer Contact

  • Saophalkun Ponlu <phalkunz (at) silverstripe (dot) com>

  • Will Rossiter <will (at) fullscreen (dot) io>

Requirements

Silverstripe 4.0+

Note: For Silverstripe 3.x, please use the 2.x release line.

Install

To install run composer require silverstripe/spamprotection.

Documentation

This module provides a generic, consistent API for adding spam protection to your Silverstripe Forms. This does not provide any spam protection out of the box. For that, you must also download one of the spam protection implementations. Currently available options are:

As a developer you can also provide your own protector by creating a class which implements the \SilverStripe\SpamProtection\SpamProtector interface. More on that below.

Configuring

After installing this module and a protector of your choice (i.e mollom) you'll need to rebuild your database through dev/build and set the default protector via SilverStripe's config system. This will update any Form instances that have spam protection hooks with that protector.

mysite/_config/spamprotection.yml

---
name: mycustomspamprotection
---
SilverStripe\SpamProtection\Extension\FormSpamProtectionExtension:
  default_spam_protector: MollomSpamProtector

To add spam protection to your form instance call enableSpamProtection.

// your existing form code
$form = new Form(/* .. */);
$form->enableSpamProtection();

The logic to perform the actual spam validation is controlled by each of the individual SpamProtector implementations since they each require a different implementation client side or server side.

Options

enableSpamProtection takes a hash of optional configuration values.

$form->enableSpamProtection(array(
    'protector' => MathSpamProtector::class,
    'name' => 'Captcha'
));

Options to configure are:

  • protector: a class name string or class instance which implements \SilverStripe\SpamProtection\SpamProtector. Defaults to your SilverStripe\SpamProtection\Extension\FormSpamProtectionExtension.default_spam_protector value.

  • name: the form field name argument for the Captcha. Defaults to Captcha.

  • title: title of the Captcha form field. Defaults to ''

  • insertBefore: name of existing field to insert the spam protection field prior to

  • mapping: an array mapping of the Form fields to the standardised list of field names. The list of standardised fields to pass to the spam protector are:

title
body
contextUrl
contextTitle
authorName
authorMail
authorUrl
authorIp
authorId

Defining your own SpamProtector

Any class that implements \SilverStripe\SpamProtection\SpamProtector and the getFormField() method can be set as the spam protector. The getFormField() method returns the FormField to be inserted into the Form. The FormField returned should be in charge of the validation process.

<?php

use CaptchaField;
use SilverStripe\SpamProtection\SpamProtector;

class CustomSpamProtector implements SpamProtector
{
    public function getFormField($name = null, $title = null, $value = null)
    {
        // CaptchaField is an imagined class which has some functionality.
        // See silverstripe-mollom module for an example.
        return new CaptchaField($name, $title, $value);
	}
}

Using Spam Protection with User Forms

This module provides an EditableSpamProtectionField wrapper which you can add to your UserForm instances. After installing this module and running /dev/build to rebuild the database, your Form Builder interface will have an option for Spam Protection Field. The type of spam protection used will be based on your currently selected SpamProtector instance.

Releasing code with Spam Protection support

Spam protection is useful to provide but in some cases we do not want to require the developer to use spam protection. In that case, modules can provide the following pattern:

use SilverStripe\Forms\Form;
use SilverStripe\SpamProtection\Extension\FormSpamProtectionExtension;

$form = new Form(/* .. */);

if ($form->hasExtension(FormSpamProtectionExtension::class)) {
    $form->enableSpamProtection();
}