Skip to content
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

Schema with a wrong pointers to subschema passes the validation #41

Open
kool79 opened this issue Dec 5, 2023 · 2 comments
Open

Schema with a wrong pointers to subschema passes the validation #41

kool79 opened this issue Dec 5, 2023 · 2 comments

Comments

@kool79
Copy link
Contributor

kool79 commented Dec 5, 2023

Given the schema:

{
	"$defs":{ "myType": {"type": "string"}},  
	"properties":{"myProperty": {"$ref": "#/$defs/MyType"}}  
}

with the wrong pointer to the type of 'myProperty' (for example, when type is misspelled). This schema succesfully pass the next json:

{ "myProperty": 0}

I expect that library should fail when I load the schema (with the GeneraionException or StandardGenerationException).
Currently the library passes such verification with a warning: WARNING: No match for #/$defs/MyType. But I cannot get 'programmatic' access to this case, so all warnings just leave in logs

Reason:
As I understand the standard, we cannot define the ref "#/$defs/myType2" in some another file and should be resolved in current context. So all local refrences must be available at schema resolution stage

Such behavior is critical in my application, where the library is used for schema linting as well. Will be good to have errors during schema load (for local refrences) of when schema is validated (for absolute refrences in external files).

@kool79 kool79 changed the title Schema with a wrong pointers to subschema passed the validation Schema with a wrong pointers to subschema passes the validation Dec 5, 2023
@kool79
Copy link
Contributor Author

kool79 commented Dec 5, 2023

When I add the "id" to schema:

{ "$id": "https://myserver.com/types/xxx",
  "$defs": { "myType": "string"},
  "properties": {"myProperty": { "$ref": "#/$defs/MyType"}}}

I have the next line in log:
WARNING: Failed attempt to auto fetch to resolve: https://myserver.com/types/xxx#/$defs/MyType
Is it expected that library should try to fetch the resouce with id which already exists? By rfc3986 this should not happens.

P.S. I use new SchemaStore().loadSchemaJson(...)

P.P.S It is definetly the anothe issue, but still try to investigate here.
Seems I've found the reason but still not sure if it is correct. In the code we have uri.isAbsolute(). During debugging I have the value https://myserver.com/types/xxx#/$defs/MyType inside the uri. So I stepped into code block which tries to fetch this uri.
But according to documentation here and here: rfc3986 the absolute uri should not contain the #fragment.
So maybe it is required to truncate the #fragment part when check condition in the line 153. In such case the uri https://myserver.com/types/xxx#/$defs/MyType will become https://myserver.com/types/xxx and condition will fail. It is because uri already exists in the canonicalUriToObject, since our ref contains in the same schema with the same id

@sranger
Copy link

sranger commented Feb 7, 2024

I was using an older version (0.10.0) but updated to the latest (0.12.3) and the json pointer path loading seemed to break for me as well. I don't see a way to request the Schema subset after loading the full schema via the json pointer, either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants