"JSON Type.vi" incorrectly evaluates string within braces
Evaluation of JSON type is incorrect when a string within curly brackets is used. For example, a UUID4 generated string that contains braces will report as "JSON Object" instead of "Not a JSON Value".
{fab8b6c7-04b6-4ef3-b31a-d204d22ce6ad}
is not a valid JSON object
Comments (8)
-
repo owner -
It would work if it starts with braces indeed, but “Next JSON Value” does not systematically work either.
For example, the following string asserts as a Number:
160E3E123-0000-048E
While this one asserts as Not a JSON String:
160E3F123-0000-048E
The bug is actually in the “Advance past Number.vi” (called by both “JSON Type” and “Next JSON Value” where multiple negative, positive or exponential signs are resulting as “Number”. In the second string example, the presence of any hexadecimal char “ABCDF” will correctly assert to Not a JSON string, but for all strings with a mix of digits, dot, +/- and “eE”, it will incorrectly assert as a number.
Ideally, the algorithm should verify if “+/-” chars are either leading characters, following an exponential character or preceding the imaginary part of a number. The algorithm should also ensure that the exponential part can only be in the count of “0 or 1” for real numbers and “0, 1 or 2” for imaginary numbers.
I’ll find a workaround, but to comply with JSON-RPC 2.0, the “id” field is required to support both a string or a numeric. Therefore, it is important that the assertion can be made to allow building the JSON packet correctly. Whether I use “JSON Type.vi” or “Next JSON Value.vi”, the result is the same, with slightly different failure surface area.
(EDIT: Since there are no standard ways in JSON spec to represent imaginary numbers, a validator that works for real numbers would be sufficient).
-
repo owner Technically, I don’t make a specification in JSONtext as to handling non-valid JSON entered into the “JSON” inputs. This is partly because I have a design goal of high speed, and extensive validation can require a loss of speed. However, I looks like I can rewrite “Advance past Number.vi” such that it rejects obvious non-numbers without compromising speed.
We can also consider more explicit API validation functions (which can do extra validation steps)
-
repo owner Added (currently failing) cases to “Test Case Error or No Error” unit test.
-
repo owner BTW, you will never entirely get your design to work, since a User entry like ‘160E3’ can be intended either as a number or as a string. To be 100% reliable, you need to explicitly know the type, rather than inferring it from the LabVIEW string.
-
repo owner -
assigned issue to
-
assigned issue to
-
repo owner Note: Permissive read of numbers not to JSON spec that I am keeping, as they are valid human-writable numbers:
.1
1.
01
+1 -
repo owner - changed status to resolved
Resolving. Now doesn't accept obvious non-numbers. Note that this is still not an input-validation function.
- Log in to comment
“JSON Type” only infers the type from the lead character, rather than doing ( a time-consuming) validation that you have entered actual JSON. If you want the validation (and thus get “Not a JSON Value”) use “Next JSON Value”.
Perhaps I should mention “Next JSON Value” as an alternative in the documentation for “JSON Type”.