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

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

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

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.

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

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):