-
-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Not automatically resolving remote references (in 4.18) breaks backwards compatibility #1089
Comments
Oh, right, this is definitely semi-intentional (see the docs) -- as doing so is a security risk in general which has only stuck around this long for backwards compat -- I did certainly forget that if you provide neither a ref resolver nor a registry (for the new API) that this does immediately break that compatibility. Will have to think about what to do / whether to re-introduce a deprecation period for this case. Though you should certainly stop doing it! |
I see. I might have a look at this once I am however very concerned about readability and quick editing. Therefore, I might implement a registry that ignores |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Changing this without deprecation is backwards incompatible, so we re-introduce a warning. This only applies if you have not configured neither a Registry nor a legacy RefResolver. Both of the former 2 cases already have 'correct' behavior (the former will not automatically retrieve references and is not backwards incompatible as it is a new API, and the latter will do so but is already fully deprecated by this release). Cloess: #1089
OK, this has now been re-enabled (with specific deprecation warnings for the behavior even if you weren't configuring It will stick around until |
In other words when someone does *not* do Validator(..., registry=...) This both limits the case which we *do* still perform automatic remote ref retrieval (in a way that still preserves backwards compatibility given that the registry argument did not previously exist, so someone using it must be doing something new) as well as fixes an issue with creating a validator with a registry that has a retrieve function. Previously the latter raised a ValueError (coming from referencing which doesn't want you combining registries unless they agree about retrieval functions. See the added test(s) for details). Fixes the issue mentioned here: #1065 (comment) Refs: #1089
Even the most basic use case of fetching a HTTPS ref fails. I.e. with the simple schema:
I've tried a few others.
In
4.17.3
, thejsonschema.validate(...)
call prints nothing (returnsNone
) as expected.The text was updated successfully, but these errors were encountered: