Schema not reachable via $id about schema HOT 9 CLOSED

@dbrgn as is just consulted the standard on that matter, you seem to be right. it says:

Note that this URI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from its canonical URI.

which i find very confusing. So you can pull in other schemas via "$ref" : "https://schema.spaceapi.io/13.json", but they are not guaranteed to be network reachable.

In the case that it is not intended to deploy the noted uri over network, i personally would prefer an uri like urn:spaceapi:schema:root:0.13, not an actual url with https:// protocol an so on. just something to consider.

from schema.

In XML, external entities and external schemas have caused a whole load of security and information disclosure vulnerabilities

yes, i am aware of this. my specific usecase also was not to load the schemas in automatically, because i am not implementing a validator, just validation. i just wanted to tell the validator where to get his schemas from. i now include them in the project directly.

on the confusion part i stand by my opinion, that an uri would be much less confusing than an url that is not reachable.

from schema.

I don't think the $id needs to be reachable, or should it? My understanding is that domains / URLs are just used for namespacing.

from schema.

I think "pulling in other schemas" will never actually download the schema, it's only a reference. Or is there any OpenAPI client that actually does that?

In any case, I agree that an URN might be better! What do you think, @gidsi?

from schema.

i am not aware of one, but i am just in the process of implementing validation for the SpaceAPI and stumbled over this scenario. i could imagine other people would, too.

probably this is due my lack of experience with json schema, i just assumed it would work like i know it from xml.

from schema.

It's definitely possible and i would like to make the schema available under the url (we've even talked about it, maybe there is even something in the protocols). Unfortunately we had a lot of other stuff on the agenda (if we start doing that we might also restructuring the schema files while we're on it).

Thats what the json-schema documentation says about using refs.

Even though the value of a $ref is a URI, it is not a network locator, only an identifier. This means that the schema doesn’t need to be accessible at that URI, but it may be. It is basically up to the validator implementation how external schema URIs will be handled, but one should not assume the validator will fetch network resources indicated in $ref values.

I would be against URN since nobody is using it out there and it might be confusing too.

from schema.

I would be against URN since nobody is using it out there and it might be confusing too.

If it's just a unique identifier, then it's perfectly fine, right?

but one should not assume the validator will fetch network resources indicated in $ref values.

Also, that should usually not ever be done implicitly. In XML, external entities and external schemas have caused a whole load of security and information disclosure vulnerabilities: https://owasp.org/www-project-cheat-sheets/cheatsheets/XML_Security_Cheat_Sheet.html

I would not be against using URLs if the schema is actually served there. But I'm not sure if automatic fetching of referenced schemas should be encouraged.

from schema.

If it's just a unique identifier, then it's perfectly fine, right?

I'm not a 100% sure what you mean.

It's best practice to use your domain (json schema doc) and i would just do that instead of using an URN.

In my opinion we would just make the schemas reachable via https if it's confusing to not have it reachable there.

from schema.

Fixed by #73

from schema.