Sending back Validation Errors

Hi Robert,

Good catch! We have to add a note about it, but I think it would be done in the Symfony Forms tutorial.

Thank you for this notice!

Cheers!

Hey @Coder!

You’re totally right - isn’t that strange? :)

I believe the method behaves the way it does mostly for historical and some internal reasons. There was actually a GitHub issue about this opened within the past year that i agree with - it’s just confusing. You can call getErrors(true) to get all the errors, but it’s not obvious. It also doesn’t keep the key of where the error came from... so it’s not ideal.

So, from a DX point of view, I think this is something we should improve so that devs have less WTF. From an API perspective, there is now support for serializing validation errors. Basically, if you use the validator directly (not through the form system) you can serialize the errors through the Symfony validator and it will turn into really nice JSON.

I hope that explains it a bit - great question!

Hey Slawek!

Symfony's Form Component doesn't allow you to have more fields than the ones you have specified in your form type, but you can configure that behaviour by using the "option resolver"

//your FormType class
    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefaults([
            'allow_extra_fields' => true
        ]);
    }

Have a nice day!

Understand. But I think about diffrent case. Like a have a form with field "name". When I send a POST with JSON {"naem": "value} - so I misspell, "naem" -> should be "name". I get information "This form should not contain extra fields." But better info would be something like this -> "naem field do not exist".

Ohh I got you now!

Look's like Symfony doesn't do it by default, in that case you would have to validate every form field by hand and add the desired error message to it

Cheers!

I have written a function to get information about "extra fields" in form. Maybe it will be usefull for others. I think it's must have for every API on Symfony form.
public function throwValidationErrorsResponse(FormInterface $form, Request $request)
{
$jsonData = $request->getContent();

$arrayData = json_decode($jsonData, true);

$data = array_flip($arrayData);

$children = $form->all();

$arr = [];

foreach ($children as $ch) {
$arr []= $ch->getName();
}

$data = array_diff($data, $arr);

$errors = $this->getErrorsFromForm($form);

array_push($errors, ['extra_fields' => $data]);

$apiProblem = new ApiProblem(
400,
ApiProblem::TYPE_VALIDATION_ERROR
);
$apiProblem->set('errors', $errors);

throw new ApiProblemException($apiProblem);
}

I have found a little bug. But here is the fix:

$jsonData = $request->getContent();

$arrayData = json_decode($jsonData, true);

$arrayForm = $form->all();

$data = array_diff_key($arrayData, $arrayForm);

$errors = $this->getErrorsFromForm($form);

if($data){
array_push($errors, ['extra_fields' => $data]);
}

$apiProblem = new ApiProblem(
400,
ApiProblem::TYPE_VALIDATION_ERROR
);
$apiProblem->set('errors', $errors);

throw new ApiProblemException($apiProblem);

Thanks for sharing your solution, I bet someone will find it useful ;)

Cheers!

Hey Nina!

That's probably my mistake :). Try this instead:

./bin/phpunit -c app/ --filter testValidationErrors

In Linux, the bin/phpunit file is sym-link to a PHP file, so you can execute it by saying php bin/phpunit or ./bin/phpunit. But on Windows, this is a .bat file, and so it needs to be executed with the ./ syntax. Basically, I should always use the ./bin/phpunit syntax. So, probably my mistake!

Let me know if it helps! And cheers!

SOVLED!

1. The GET request from browser won't get the $data array, that's why my browser returns more fields than a POST request from Guzzle;
2. I used the

try{/*your requests*/} 
catch (ClientException $e){ 
$response = $e->getResponse();
//verify assertions here, although it's a bit odd as some assertor() functions doesn't work properly
} 

I suspect it's the guzzle version issue, it threw 400 error (as it should) before assertions codes were reached so I failed my test.
I am a RESTful newbie, if it's not right, please let me know, cheers! :)

Best regards,
Sheeran

Yo Chan Sheeran!

Sorry for my late reply, but even better you figured it out for yourself. You're 100% correct on (1) - that's part of the reason we have some "tricks" in our base test class to help print the response in the terminal - it's not always something you can see just by going to the browser!

About (2), by default, Guzzle throws an exception whenever the response is a 400 or 500 status code. However, in ApiTestCase, we add some configuration that says to NOT do this, as it makes testing a bit more difficult. I see you're using Guzzle 6 - check out the code download for episode 4 of this series (where the code has been upgraded to Guzzle 6) - you'll see the http_errors => false line that configures our client this way). Did you possibly change the ApiTestCase code to use new Guzzle, but without this option? It's really fine either way - you can let Guzzle throw exceptions or turn them off - obviously, it just changes how your code will look :).

And welcome to REST - it's tricky, but powerful!

Cheers!

Hi, Ryan,

Thanks for your reply!

Yes, I modified the codes from your tutorials to fit my project, they works like a charm now. Thanks for all these efforts, I learnt a lot from you. I will carry on to buy more after I finish these big tricky part, very helpful and interesting, thanks again to your team and you for these brilliant works!

Cheers!

Sheeran

Cheers buddy! And good luck! :)

Hey!

Ah, lame! Hmm, it looks like that error usually comes when you're trying to decode a date or do something (like multiplication) with a non-number... but I can't think of where we would be sing that!

So, let's do some debugging! First, do you always get this error no matter what values you fill in for your fields? Second, can you use the tricks on this page - https://knpuniversity.com/s... - to see if you can see a stacktrace for the error? I'm sure if we can see a stracktrace (if you find it, you could take a screenshot or copy-paste), I'm sure we'll be able to hunt down the cause!

Cheers!

Ryan, did some digging myself as i ran into the same problem. i have my CLI running PHP 7.1 by default. Found this PR request for symfony 2.7 https://github.com/symfony/.... seems like this is the problem.

To fix the issue i just changed the composer file to read the following:

....
"require": {
"php": ">=7.1",
"symfony/symfony": "2.7.*",
....
},
....

Thanks,
Jordan Wamser

Hey jmwamser!

Wow, nice find! Thanks for sharing it - that's super subtle :)

Cheers!