Skip to content

Banned Markup

Validates that a given string does not contain a configured type of markup.

It can recognize HTML and BBCode.

Can be applied to properties or methods.

How strict is the detection of the markup types?

Markup detection is loose on purpose, and will also flag “lame attempts” that are not valid, while at the same time trying to keep the chance of false positives as low as possible. Spambots are not known to strictly adhere to internet standards so being really strict would only reduce effectiveness.

Basic Usage

namespace App\Entity;

use Omines\AntiSpamBundle\Validator\Constraints as Antispam;

class Message
{
    #[Antispam\BannedMarkup]
    protected string $content;
}

# config/validator/validation.yaml
App\Entity\Message:
    properties:
        content:
            - BannedMarkup:

// src/Entity/Participant.php
namespace App\Entity;

use Omines\AntiSpamBundle\Validator\Constraints as Antispam;
use Symfony\Component\Validator\Mapping\ClassMetadata;

class Message
{
// ...

    public static function loadValidatorMetadata(ClassMetadata $metadata): void
    {
        $metadata->addPropertyConstraint('content', new Antispam\BannedMarkup());
    }
}

Null values are always valid

As with most of Symfony’s own constraints, null is considered a valid value. This is to allow the use of optional values. If the value is mandatory, a common solution is to combine this constraint with NotBlank.

Options

bbcode

type: boolean default: true

If set to true validation will fail if the given value contains tags resembling BBCode.

groups

type: array|string default: null

It defines the validation group or groups of this constraint. Read more about validation groups.

html

type: boolean default: true

If set to true validation will fail if the given value contains tags resembling HTML.

passive

type: bool default: null, defaulting to bundle configuration

When in passive mode the constraint will not generate a validation error, but still dispatch its regular events.

With default bundle configuration passive mode is disabled.

payload

type: mixed default: null

This option can be used to attach arbitrary domain-specific data to a constraint. The configured payload is not used by the Validator component, but its processing is completely up to you.

For example, you may want to use several error levels to present failed constraints differently in the front-end depending on the severity of the error.

stealth

type: bool default: null, defaulting to bundle configuration

With stealth mode disabled the validator will generate a verbose error, similar to Symfony built-in constraints, explaining for precisely which reasons what rule was validated.

If stealth mode is enabled instead the validator only shows a generic error message, stating that form submission failed and the user should contact the website administrator for further assistance.

With default bundle configuration stealth mode is disabled by default when used standalone, and enabled by default when applied as part of an anti-spam profile.