You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can probably get around this by using file:// in the $ref.
However, this is not needed if $ref is used in the properties entry.
I noticed that the function resolveThenPopulateSchema() and makeOrReuseSchema() handle refs different.
I copied the logic from makeOrReuseSchema() and at least in my case this fixed it.
diff --git a/ext/valijson-1.0.3/include/valijson/schema_parser.hpp b/ext/valijson-1.0.3/include/valijson/schema_parser.hpp
index fef97b3f5..40763d989 100644
--- a/ext/valijson-1.0.3/include/valijson/schema_parser.hpp
+++ b/ext/valijson-1.0.3/include/valijson/schema_parser.hpp
@@ -1013,23 +1013,44 @@ private:
const std::string actualJsonPointer = sanitiseJsonPointer(
internal::json_reference::getJsonReferencePointer(jsonRef));
- if (documentUri && (internal::uri::isUriAbsolute(*documentUri) || internal::uri::isUrn(*documentUri))) {
- // Resolve reference against remote document
- if (!fetchDoc) {
- throwRuntimeError("Fetching of remote JSON References not enabled.");
- }
- const typename DocumentCache<AdapterType>::DocumentType *newDoc = fetchDoc(*documentUri);
+ // Determine the actual document URI based on the resolution
+ // scope. An absolute document URI will take precedence when
+ // present, otherwise we need to resolve the URI relative to
+ // the current resolution scope
+ const opt::optional<std::string> actualDocumentUri = resolveDocumentUri(currentScope, documentUri);
- // Can't proceed without the remote document
- if (!newDoc) {
- throwRuntimeError("Failed to fetch referenced schema document: " + *documentUri);
- }
+ if (actualDocumentUri && (!currentScope || *actualDocumentUri != *currentScope)) {
+ const typename FunctionPtrs<AdapterType>::DocumentType *newDoc = nullptr;
+
+ // Have we seen this document before?
+ typename DocumentCache<AdapterType>::Type::iterator docCacheItr =
+ docCache.find(*actualDocumentUri);
+ if (docCacheItr == docCache.end()) {
+ // Resolve reference against remote document
+ if (!fetchDoc) {
+ throwRuntimeError("Fetching of remote JSON References not enabled.");
+ }
- // Add to document cache
- typedef typename DocumentCache<AdapterType>::Type::value_type DocCacheValueType;
+ // Returns a pointer to the remote document that was
+ // retrieved, or null if retrieval failed. This class
+ // will take ownership of the pointer, and call freeDoc
+ // when it is no longer needed.
+ newDoc = fetchDoc(*actualDocumentUri);
+
+ // Can't proceed without the remote document
+ if (!newDoc) {
+ throwRuntimeError("Failed to fetch referenced schema document: " + *actualDocumentUri);
+ }
- docCache.insert(DocCacheValueType(*documentUri, newDoc));
+ typedef typename DocumentCache<AdapterType>::Type::value_type
+ DocCacheValueType;
+
+ docCache.insert(DocCacheValueType(*actualDocumentUri, newDoc));
+
+ } else {
+ newDoc = docCacheItr->second;
+ }
const AdapterType newRootNode(*newDoc);
Can you please check it?
Maybe it is a good idea to unify the behavior?
In addition to this, can you please add a new flag to disable the warning for the RAPIDJSON_ASSERT?
#warning "RAPIDJSON_ASSERT already defined."
#warning "Please include valijson/adapters/rapidjson_adapter.hpp before any RapidJSON headers."
I would like to use my own version. Is it even necessary?
Best regards,
Chris
The text was updated successfully, but these errors were encountered:
Hi,
I found a crash due to infinite recursion while using local remote schemas.
I use following schemes:
MainSchema.schema.json:
RemoteSchema.schema.json:
You can probably get around this by using file:// in the $ref.
However, this is not needed if $ref is used in the properties entry.
I noticed that the function resolveThenPopulateSchema() and makeOrReuseSchema() handle refs different.
I copied the logic from makeOrReuseSchema() and at least in my case this fixed it.
Can you please check it?
Maybe it is a good idea to unify the behavior?
In addition to this, can you please add a new flag to disable the warning for the RAPIDJSON_ASSERT?
I would like to use my own version. Is it even necessary?
Best regards,
Chris
The text was updated successfully, but these errors were encountered: