New in Symfony 7.1: Constraint Improvements

Range Validation in Ip and Cidr Constraints

The Cidr constraint and the Ip constraint allow defining the type of CIDR or IP considered valid (e.g. IPv4, IPv6, both). In Symfony 7.1 we're improving them with new types: *_NO_PUBLIC (check that the IP address is not public), *_ONLY_PRIVATE (check that the IP address is a private one) and *_ONLY_RESERVED (check that the IP address is a reserved one).

In these constants, the * can be replaced with V4 (to only support IPv4 addresses), V6 (only support IPv6 addresses) or ALL (to support both). In addition, the Cidr constraint can now use the exact same types as the Ip constraint, including the new ones added in Symfony 7.1.

Make the Password Strength Available

Contributed by Christian Flothmann in #54479

The PasswordStrength constraint checks that the given password has reached the minimum strength required by the constraint. There are several levels to define the minimum required strength, from PasswordStrength::STRENGTH_WEAK (1) to PasswordStrength::STRENGTH_VERY_STRONG (4).

In Symfony 7.1, we're adding the strength value as a parameter in the constraint violation error message. This way, you can use this value to customize the error message depending on the strength of the password input by the user.

Deprecated some Bic Constraint Error

Contributed by Mathieu Lechat in #54535

The Bic constraint checks that a given value has the proper format of a BIC (Business Identifier Code). This code , also known as SWIFT-BIC, SWIFT ID, or SWIFT code, is used for example in IBAN (International Bank Account Number) codes.

In Symfony 7.1 we're improving this constraint to deprecate the Bic::INVALID_BANK_CODE_ERROR (it will be removed in Symfony 8.0). The reason is that this error is associated with a validation that checks that the BIC's first four characters are letters.

This was assumed to be true because ISO 9362 says that "we have no plan to issue BICs with numeric characters in the first 4 characters" but later it mentions that this could happen. Indeed, this happened to a member of the Symfony community when validating an IBAN from a UAE bank.

A good example of how a framework like Symfony makes you more productive by solving low-level and boring problems so you don't even have to be aware of them.

New Types Added to the Type Constraint

Contributed by Florian Hermann in #52954

The Type constraint checks that a given value is of a specific data type like an integer or an array. In addition to built-in PHP types, this constraint supports some additional types. In Symfony 7.1 we've added two more types: list and associative_array.

1
2
3
4
5
6
7

use Symfony\Component\Validator\Constraints as Assert;

#[Assert\Type('list')]
private $someValue;

#[Assert\Type('associative_array')]
private $anotherValue;

When to use each of them?

• A list is a PHP array where all its keys are consecutive integers from 0 to count($array) - 1. Internally, it uses the array_is_list() PHP function to perform this check;
• An associative_array value is an array that is not a list.

Allow to Require a TLD in Url Constraint

Contributed by Javier Eguiluz in #54408

The Url constraint checks that the given value is a valid URL string. Deciding what a valid URL is looks pretty simple. However, the URL spec is liberal and considers valid URLs values like https://aaa, https://foobar, and https://this_is_not_a_url.

In Symfony 7.1, we've added a requireTld option (false by default) to check that the given URL has at least one TLD (e.g. https://aaa is not valid but https://aaa.org is valid; https://example is not valid but https://example.com.org is valid):

1
2
3
4
5
6
7

use Symfony\Component\Validator\Constraints as Assert;

class Author
{
    #[Assert\Url(requireTld: true)]
    protected string $bioUrl;
}