You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an input body into an apigility API contains a field with a very large number, json_encode will emit a notice:
Notice: json_decode(): integer overflow detected in /vagrant_web/vendor/zfcampus/zf-content-negotiation/src/ContentTypeListener.php on line 172
It doesn't matter if the field is defined in the API or not, it will happen on any POST, PUT or PATCH.
{ "foobar": 128934701823471023487128390871 }
Since the decoding happens before any validation occurs, this is understandable. Also, unfortunately, it appears that tacking on the silence operator (@) to hide the notice actually changes the behavior. As the code sits now, the validators and the resource code will receive 9223372036854775807 for the value of those large integer containing fields.
If I send in the large number for a field with a StringLength validator, after the Notice and stack trace, I get a JSON body with the validator indicating that the field expected a string but didn't get that.
If I change line 172 to be
$data = @json_decode($json, true);
Then I don't see the notice and I'm getting the same (expected) validation errors. But the input number is smashed down to PHP_INT_MAX. There's an option on json_decode called JSON_BIGINT_AS_STRING which seems it should be able to use the large number as a string (at least that's how I read it) but it doesn't seem to have any effect whatsoever.
I'm not really happy with the @ solution since @ is evil and all that, but since JSON_BIGINT_AS_STRING doesn't appear to work and there doesn't appear to be any way at all to get the actual input in any format, I'm not sure if anything can be done.
TL;DR - If anything can be done about this that would ideally not spew a notice but could be dealt with in a way that would give back some sort of nice error (that would be JSON at the end) that would be ideal. I don't know if it's possible, though.
I wrote a test for the case you are describing, and it seems the listener is returning an ApiProblemResponse in case I pass a large number.
This seems like proper behavior, or maybe I misunderstood the issue...
The test does seem to cause an ApiProblem with a 400 status to be thrown which is fine. I don't think it was doing that when I originally opened the issue. This issue can probably be closed in that case.
Opening here as it was originally on zf-content-validation - zfcampus/zf-content-validation#57
If an input body into an apigility API contains a field with a very large number, json_encode will emit a notice:
It doesn't matter if the field is defined in the API or not, it will happen on any POST, PUT or PATCH.
Since the decoding happens before any validation occurs, this is understandable. Also, unfortunately, it appears that tacking on the silence operator (@) to hide the notice actually changes the behavior. As the code sits now, the validators and the resource code will receive 9223372036854775807 for the value of those large integer containing fields.
If I send in the large number for a field with a StringLength validator, after the Notice and stack trace, I get a JSON body with the validator indicating that the field expected a string but didn't get that.
If I change line 172 to be
Then I don't see the notice and I'm getting the same (expected) validation errors. But the input number is smashed down to PHP_INT_MAX. There's an option on json_decode called JSON_BIGINT_AS_STRING which seems it should be able to use the large number as a string (at least that's how I read it) but it doesn't seem to have any effect whatsoever.
I'm not really happy with the @ solution since @ is evil and all that, but since JSON_BIGINT_AS_STRING doesn't appear to work and there doesn't appear to be any way at all to get the actual input in any format, I'm not sure if anything can be done.
TL;DR - If anything can be done about this that would ideally not spew a notice but could be dealt with in a way that would give back some sort of nice error (that would be JSON at the end) that would be ideal. I don't know if it's possible, though.
Originally posted by @dstockto at zfcampus/zf-content-negotiation#77
The text was updated successfully, but these errors were encountered: