symfony: \Symfony\Bridge\Doctrine\Form\ChoiceList\ORMQueryBuilderLoader::getEntitiesByIds doesn't filter invalid UUIDs
When using the default Doctrine EntityType in Forms, invalid GUID/UUID values (e.g. “”, “asdf”, 1) are being run through the database, which causes exceptions when using PostgreSQL
If an invalid UUID is submitted in a form (including empty values, which ends up being sent to Postgres as “”) an exception is thrown, e.g.
SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for uuid: \"\"
The class already filters out non-int values for single int id entities for the same reason; because it causes an error on Postgres (see commit 45579fd7cd792eca9e4fdc90b34dd18523441137). So it makes sense to me to run a similar check for valid UUID values.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 27 (10 by maintainers)
@webmozart that’s true, they could be. However the issue is when you’re specifically using the
guidcolumn type and pass a non-valid guid string to postres, an exception is thrown. If you want strings of any format you should be using thestringcolumn type.Because the
EntityTypeclass uses theORMQueryBuilderLoader, anything submitted to a form will get pumped directly into the database. So if I have a REST API where someone sends through an invalid guid it’s going to cause an error. At the moment I can fix this by filtering input values in a pre-submit form listener that checks UUID validity, but obviously I have to know to do that, and it gets more complicated as entities are nested, there are collections, and so on.So out of the box, if I create an entity with a guid type primary key, use Postres as my database, and create a form with an
EntityTypefield with my new entity. As soon as someone submits the form with an invalid guid value a 500 error will result.this bug is still valid
I was thinking of an even more generic way, because this issue means the transformer cannot rely on the
ChoiceListInterface. Here’s a quick gist that leverages the check without breaking anything in user land code if we decide to add a feature like an option flag passed to theChoicesToValuesTransformerthat can then deprecated in 5.0. On the other hand, a choice loader or custom list which does not return the same count of entries than given (on way or the other) is breaking the interface contract. So it makes senses that these implementations handle the case by throwing an exception, but it not their responsibility to throw aTransformationFailedExceptionthough.