Description
Symfony version(s) affected
7.2
Description
I'm currently trying to implement a simple denormalizer for API platform that allows invalid UUID values like "abc" to hit the validator of the DTO property path instead of producing a hard "The input data is misformatted." exception. First I thought it might be a quirk within the vendor, but simplifying it to the following shows some unexpected behavior:
Using symfony/uids own commands I get the following:
bin/console uuid:generate --random-based
8131873f-5df8-49c2-92af-38ee4c0bfbb2
bin/console uuid:inspect 8131873f-5df8-49c2-92af-38ee4c0bfbb2
----------------------- --------------------------------------
Label Value
----------------------- --------------------------------------
Version 4
toRfc4122 (canonical) 8131873f-5df8-49c2-92af-38ee4c0bfbb2
toBase58 GxJ74kHnMFDTtatLm9gQvV
toBase32 41663KYQFR97195BSRXS60QYXJ
toHex 0x8131873f5df849c292af38ee4c0bfbb2
----------------------- --------------------------------------
yet simple validation checks seem to be all over the place:
Uuid::isValid('8131873f-5df8-49c2-92af-38ee4c0bfbb2') // true
Uuid::isValid('41663KYQFR97195BSRXS60QYXJ'); // false
Uuid::isValid('GxJ74kHnMFDTtatLm9gQvV'); // false
Ulid::isValid('8131873f-5df8-49c2-92af-38ee4c0bfbb2') // false
Ulid::isValid('41663KYQFR97195BSRXS60QYXJ') // true
Ulid::isValid('GxJ74kHnMFDTtatLm9gQvV') // false
So I'm unsure about the following points, maybe I'm missing something and this all expected:
I see there is an attempt to satisfy the RFC by juggling a second parameter, but I do not understand why it would matter that early in the code, because a developer should be able to pass any valid-encoded value and the implementation is very strict about the encodings that can go in.
Then the whole process breaks at the point where Ulid::isValid is used within Uuid::transformToRfc9562
. What is the whole && $format & self::FORMAT_BASE_32
part protecting against, and why are we handling a Ulid all of the sudden?
A similar question was raised in #45148 but with no real outcome.
How to reproduce
See description for simple code snippets.
Possible Solution
During development I expected the following given:
Uuid:isValid
should validate any encoding, and fail ULIDs and invalid values.Ulid::isValid
should validate any encoding and fail UUIDs and invalid values.
As for the vendors weird behavior:
- UidNormalizer should be split into UuidNormalizer and UlidNormalizer if there is such a stark contrast between both and not be based on the abstract. This split is also done on the validator constraints as well.
- UidNormalizer could use RFC 9562s NilUuid as an indication that there is no processable value there, allowing the Uuid constraint to actually fail (NilUuid is invalid) instead of the de/normalizer beforehand.
Additional Context
No response