-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] Form validates although invalid choice is given with expanded=true #5113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, Thanks for taking the time to report this issue. I can confirm the problem for expanded choice fields, both single- and multiple-choice. Nevertheless, having invalid choices in such cases should be rare, i.e. limited to people playing with the POST parameters. As no invalid choices can get through, this is not a security issue either. This is somewhat tricky to fix, so I'm not sure whether the fix will make it into 2.1. Bernhard |
Hi Bernhard, We already had a look at the component, but besides some headaches we had no success finding a solution. Frank |
We'd appreciate a lot if you could open a PR on https://github.com/symfony/symfony-doc if you feel that this could help others. |
Good news :) This is fixed in the referenced PR. |
@bschussek note that this does not only happen if somebody hacks a form. There are other ways this can happen, e.g. if a form's options are dynamically set but change between the user loading the form and submitting the data. If there's anything that I can do to help get this fixed and merged sooner rather than later just let me know! |
This PR was merged into the master branch. Discussion ---------- [Form] Fixed expanded choice field to be marked invalid when unknown choices are submitted #7939 must be merged before this PR is merged. | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #5113, #5190 | License | MIT | Doc PR | - TODO: - [x] test EntityChoiceList for stricter rules - [ ] test ModelChoiceList for stricter rules - [x] remove/deprecate the ChoiceList::getIndicesFor*() methods Commits ------- 9efdb8e [Form] Deprecated ChoiceList::getIndicesFor*() methods 67ba131 [DoctrineBridge] Improved test coverage of EntityChoiceList 31e5ce5 [Form] Improved test coverage of ChoiceList classes 6283b0e [Form] Fixed expanded choice field to be marked invalid when unknown choices are submitted 79a214f [Form] Fixed ChoiceList::get*By*() methods to preserve order and array keys 62fbed6 [Form] Removed usage of the ChoiceList::getIndicesFor*() methods where they don't offer any performance benefit
In Symfony 2.0 a form is not valid when an unknown/invalid choice value is bound to a form. It does not matter if the type option expanded is set to true or false.
However with the latest changes in the Symfony master the form is now valid with this invalid choice. The invalid choice "is lost" somewhere in the form workflow and so the field is validated successfully because its value is empty and not required.
When the expanded=true option is set in the type everything is working as expected.
Besides one can pass anything as invalid choice, a string, an array the result is always the same: the form validates and the resulting field value is null. It also does not matter if the choice type gets the optional Choice constraint assigned.
Here two example test cases (without namespaces) for Symfony 2.0 and 2.1
Test case for Symfony 2.0 (form is not valid: OK):
Test case for Symfony 2 master (form is valid: FAIL!):
Maybe we are missing something, but we could not get it running.
The text was updated successfully, but these errors were encountered: