When looking into the fix for #750 I noticed an issue in an update made recently by @fdutton . There was a method introduced to convert a Legacy or JSON Path path to a JSON Pointer to make a subsequent lookup.
Specifically in PathType the following was introduced:
public String convertToJsonPointer(String path) {
switch (this) {
case JSON_POINTER: return path;
default: return fromLegacyOrJsonPath(path);
}
}
static String fromLegacyOrJsonPath(String path) {
return path
.replace("\"", "")
.replace("]", "")
.replace('[', '/')
.replace('.', '/')
.replace("$", "");
}That is used in UnEvaluatedPropertiesValidator:
public Set<ValidationMessage> validate(JsonNode node, JsonNode rootNode, String at) {
...
unevaluatedPaths.forEach(path -> {
String pointer = getPathType().convertToJsonPointer(path);
JsonNode property = rootNode.at(pointer);
if (!schema.validate(property, rootNode, path).isEmpty()) {
failingPaths.add(path);
}
});
...
}The fromLegacyOrJsonPath method of PathType is oversimplified and assumes that there are no characters with potentially special meaning in the property names being looked up. For example a property including /, ~, ", [, ], . or $ would end up with an invalid JSON pointer that would not throw an error but would never end up matching anything. In addition, as it stands, the default path approach is the legacy "JSON-Path-like" approach which may be invalid as JSON Path to begin with.
What are your thoughts @fdutton ?
When looking into the fix for #750 I noticed an issue in an update made recently by @fdutton . There was a method introduced to convert a Legacy or JSON Path path to a JSON Pointer to make a subsequent lookup.
Specifically in
PathTypethe following was introduced:That is used in
UnEvaluatedPropertiesValidator:The
fromLegacyOrJsonPathmethod ofPathTypeis oversimplified and assumes that there are no characters with potentially special meaning in the property names being looked up. For example a property including/,~,",[,],.or$would end up with an invalid JSON pointer that would not throw an error but would never end up matching anything. In addition, as it stands, the default path approach is the legacy "JSON-Path-like" approach which may be invalid as JSON Path to begin with.What are your thoughts @fdutton ?