Repository navigation
Conversation
…erences of the OpenAPI specification The parser loads every external $ref of the specification when the consumer or producer is created, from the working directory and the classpath or over http(s), and the api-doc of a contract-first REST DSL resolves them as well. The new externalReferences option (all, local, none) on the rest-openapi endpoint and component and on the openApi element of the REST DSL checks the references before the parser resolves them, in the specification and in the local documents it references, and fails the start with a message that names a reference the option does not allow. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
davsclaus
left a comment
There was a problem hiding this comment.
Thanks, nice work, and a good call to check before the parser runs rather than lean on setSafelyResolveURL. The default all keeps today's behaviour, which fits the security model (the spec is route configuration), so no upgrade-guide entry is needed. Three things before it can go in:
localcan still reach http(s) in two cases, because the checker reads nested documents differently from the parser and skips any document it cannot read (inline comments):- a referenced document in a subdirectory: the parser resolves its relative refs against that document (
ExternalRefProcessor.join(externalFile, ref)), the checker against the working directory/classpath root, so it usually finds nothing and moves on; - OpenAPI 3.1
$id:OpenAPI31Traverser.traverseSchema/ReferenceVisitor.resolveSchemaRefresolve a relative$refagainst the enclosing schemas'$id, so$id: https://host/schemas/+$ref: owner.jsonfetcheshttps://host/schemas/owner.jsonwhile the checker sees a relative file ref.
(noneis not affected: it rejects every ref that does not start with#.)
- a referenced document in a subdirectory: the parser resolves its relative refs against that document (
- Catalog not regenerated:
catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/schemas/camelYamlDsl-model.jsonis missing the newexternalReferencesattribute ofopenApi(the copy underdsl/camel-yaml-dslhas it), so CI's uncommitted-changes check will trip. Rebuildingcatalog/camel-catalogshould fix it. - Minor:
RefUtils.readExternalRef(String, RefFormat, List, Path)is deprecated in swagger-parser 2.1.48; the 5-arg overload with anullPermittedUrlsCheckerdoes the same thing.
Items 1 and 3 apply to the copy in camel-openapi-java as well.
Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
luigidemasi
left a comment
There was a problem hiding this comment.
Request changes on commit 152edec881765f17506e184e3f871564377588f8.
The additional HTTP probes confirm that none is also bypassable, through YAML aliases. I also reproduced the previously reported nested-reference and OpenAPI 3.1 $id problems, plus an OpenAPI 3.1 file: reference case. The inline comments describe the three policy defects and the missing generated catalog update. All three policy defects affect both the rest-openapi endpoint and the api-doc reader's copy of the checker.
Validation:
- Built the scoped reactor with dependencies from the exact PR checkout, then ran both complete module suites: 199 camel-rest-openapi tests and 102 camel-openapi-java tests passed, with no failures, errors or skips.
- Loopback HTTP probes reproduced five bypass cases on both call paths: nested relative references, schema
$id, ordinary YAML aliases underlocal, hash-prefixed YAML aliases undernone, and OpenAPI 3.1file:references. Each made one prohibited HTTP request and completed successfully. Direct HTTP-reference controls were rejected with zero requests. - Negating
checked.add(file)in an isolated copy causedlocalChecksTheDocumentsTheSpecificationReferencesto fail; the original focused suite passed all 13 tests. - Hosted Java 21/25 builds, documentation validation and license check remain queued. Dependency review passed; Sonar was skipped. A full-repository build was not run.
AI-generated review by Codex on behalf of Luigi De Masi (@luigidemasi).
✅ Generated files are up to dateAn earlier CI run reported uncommitted generated changes; the latest run no longer does. |
gnodet-bot
left a comment
There was a problem hiding this comment.
Security feature with good test coverage for the happy path, but several issues need addressing before this can be merged.
P1 — Security bypasses
1. YAML alias bypass
readTree() in both copies uses Yaml.mapper().readTree() (SnakeYAML/Jackson by default), which expands YAML aliases before the JSON tree is handed to scan(). A document like:
base: &anchor
$ref: 'http://evil.example.com/steal'
paths:
/foo:
get: *anchorwill deliver the resolved $ref node to scan() — but it can also be used to create alias-based billion-laughs bombs before scan() is even called. Since this is a security feature, the YAML parsing should use an alias-disabling mapper.
2. readLocalDocument resolves against CWD, not the containing document's directory
Both copies call RefUtils.readExternalRef(file, RefFormat.RELATIVE, null, new File(".").toPath()). The base path is the JVM working directory, not the directory that contains the referencing document. Given a spec at /etc/camel/specs/petstore.yaml with $ref: '../secrets/private.yaml', the checker resolves it relative to . (wherever the JVM was launched) rather than /etc/camel/specs/. This silently misclassifies references (they fail to load, fall through to the catch (RuntimeException) silent-null path) OR resolves to an unrelated file if the relative path happens to exist under CWD.
3. $id base URI not tracked
scan() only follows $ref keys. JSON Schema documents can redefine the resolution base URI with $id. A clever specification can point $id at an external origin and then use internal-looking $ref values that resolve externally once the base URI shift is applied. The checker currently has no awareness of $id and will classify such references as "local" when they are in fact remote.
P2 — Operational issues
4. Silent document drop in readLocalDocument
The catch (RuntimeException) block logs at DEBUG and returns null. When the caller sees null, it silently skips checking that document's references. If a spec refers to a file that exists but is unreadable (permissions, locked, corrupt), the security check passes with no warning to the user. This should log at WARN and/or propagate an exception so the operator knows a document could not be validated.
5. isHttp() does not handle file: URIs
isHttp() only checks http: and https: prefixes. A file: URI (e.g. $ref: 'file:///etc/passwd') will fall through to the local-document branch and be read as a local file — which may be intentional for local policy but seems surprising for none policy. If file: URIs are intentionally treated as local references, this should be explicitly documented.
Non-blocking observations
externalReferencespropagation increateEndpoint():endpoint.setExternalReferences(getExternalReferences())propagates unconditionally. This is correct (the endpoint's own value overrides at configuration time if set), but worth verifying the precedence semantics are as intended.- Both
OpenApiExternalReferences.javacopies are structurally identical. It would reduce maintenance burden to keep only one implementation or factor the shared logic into a common utility.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 567 of 707 tested, 20 compile-only — current: 567 all testedMaveniverse Scalpel detected 567 affected modules (current approach: 567). Skip-tests mode would test 567 modules (13 direct + 561 downstream), skip tests for 20 (generated code, meta-modules) Modules Scalpel would test (567)
Modules with tests skipped (20)
💡 Manual integration tests recommended:
Build reactor — dependencies compiled but only changed modules were tested (13 modules, 4m 40s total)Total reactor time: 4m 40s
Top 20 slowest modules:
|
davsclaus
left a comment
There was a problem hiding this comment.
Re-review of 152edec..f48bfa0. Thanks Andrea.
The only new commit is "Regen", so most of my earlier review still stands.
Fixed:
- Earlier point 2 (catalog not regenerated): the catalog copy of
camelYamlDsl-model.jsonnow matches the one indsl/camel-yaml-dsl, and CI is green. Luigi's thread on that file can be resolved.
Still open:
- blocking: nested references (my thread on line 125; Luigi and gnodet-bot raised the same thing on lines 121-125, in both copies). This has not changed.
readLocalDocumentstill resolves every nested ref againstnew File("."), and returnsnullwhen it cannot read a document. A$refinsideschemas/pet.yamlis therefore not read from where the parser reads it, and an http ref in that document gets through underlocal.file:refs fail the same way, because they are read asRefFormat.RELATIVE. Afile:ref is fine underlocal, but its own refs are never checked. Resolving each ref against the document that contains it, reading with the ref's own format (RefUtils.computeRefFormat) and throwing when a document cannot be read would cover all of these. - blocking: OpenAPI 3.1
$id(my thread on line 156, Luigi's on line 184). Not changed. - blocking (raised by Luigi, which I missed): YAML aliases. I checked this against the libraries.
Yaml.mapper().readTree(jackson-dataformat-yaml) returns an alias*xas the plain stringx. swagger-parser reads YAML with SnakeYAMLYaml.load(DeserializationUtils.readYamlTree), which expands the alias. So a$refgiven as an alias of an http URL passes the check, underlocaland, with an anchor name starting with#, undernonetoo. IfreadTreeusedDeserializationUtils.deserializeIntoTree(content, location), the checker would scan the same tree the parser resolves, with aliases expanded and the parser's alias limits applied. - not blocking: the deprecated
RefUtils.readExternalRef(String, RefFormat, List, Path)is still used. The 5-arg overload with anullPermittedUrlsCheckerdoes the same thing. - not blocking: the
checkedset and the document name used for nested refs (inline comment).
Tests: points 1-3 each need a regression test that expects the start (or api-doc) to fail with no http request made, in both camel-rest-openapi and camel-openapi-java. Luigi asked for the same. For example, use a referenced document in a subdirectory, a 3.1 schema with $id, and a $ref that is an alias.
All points apply to both copies of OpenApiExternalReferences.
Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
…ay the parser resolves them The checker now scans the tree the parser builds (YAML aliases expanded), resolves each reference against the document that contains it and, for OpenAPI 3.1, against the enclosing $id, reads file: and classpath: documents as the parser does, and fails when a referenced document cannot be read. Regression tests for nested documents, $id, aliases and file: references in both modules. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Following up on my earlier review — all five issues raised on 2026-10-20 are addressed in commit 47ac40a. The rewrite is solid: YAML aliases are now expanded before the policy check via DeserializationUtils.deserializeIntoTree(), each reference is resolved against its containing document using ExternalRefProcessor.join() (OpenAPI 3.0) and ReferenceUtils.resolve() with the $id chain (OpenAPI 3.1), unreadable documents fail closed with a diagnostic message, and the tests cover all the key edge cases including aliases, subdirectory resolution, $id redirection, file: URIs, and remote specifications.
One small metadata inconsistency remains (see inline).
This review was generated by an AI agent, Hermès on behalf of @gnodet.
davsclaus
left a comment
There was a problem hiding this comment.
Re-review of f48bfa0..47ac40a. Thanks Andrea, this is a careful rewrite.
Fixed from my earlier reviews:
- Nested references: each
$refis now resolved against the document that contains it (ExternalRefProcessor.joinfor 3.0,ReferenceUtils.resolvefor 3.1), read the way the parser reads it (file:/classpath:by path, otherwise the 5-argRefUtils.readExternalRef), and a document that cannot be read now fails the check instead of being skipped.localChecksTheReferencesOfADocumentInASubdirectory,localChecksADocumentReferencedByAbsolutePathandlocalFailsWhenAReferencedDocumentCannotBeReadcover this. - OpenAPI 3.1
$id: the scan carries the$idchain asOpenAPI31Traverser.traverseSchemadoes, and the policy is applied to the resolved target.localRejectsAnOpenApi31ReferenceResolvedAgainstAnHttpId(zero requests) plus theallcontrol cover this. - YAML aliases: the checker now scans
DeserializationUtils.deserializeIntoTree, the same tree the parser resolves, so*#remoteundernoneand an ordinary alias underlocalare both rejected with zero requests. - The deprecated 4-arg
RefUtils.readExternalRefis gone. checkedand the document name now hold the resolved location.
The regression tests for points 1-3 are in both camel-rest-openapi and camel-openapi-java, and both copies of OpenApiExternalReferences are identical apart from the package and the class comment. Reading a remote specification once and handing it to readContents(content, null, options, location) keeps the default path unchanged, which is a nice touch.
Luigi's and gnodet-bot's threads about the same points look addressed too (gnodet-bot confirmed in its follow-up). Luigi, could you check yours and resolve them if you agree?
Still open, not blocking: gnodet-bot's point on OpenApiDefinition (line 67). The externalReferences attribute has no label = "security", while the endpoint and component option do, so the catalog shows it under common for the REST DSL. Adding the label (and regenerating) would keep the grouping consistent.
Conventions check: the commit, branch and JIRA linkage follow the project guidelines, and the generated files and catalog are in sync (CI is green on Java 21 and 25). No upgrade-guide entry is needed, since the default all keeps today's behaviour. The tests use AssertJ in camel-rest-openapi and JUnit in camel-openapi-java, which matches each module. Neither uses Thread.sleep.
Before approving, I'd like to go over a couple of remaining cases with Andrea directly.
This review covers project rules and conventions only. It does not replace CodeRabbit, Sourcery or SonarCloud.
Claude Code on behalf of Claus Ibsen
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
…f openApi as security, like the endpoint and component options Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Following up on my earlier review — the remaining open issue (missing label = "security" on externalReferences in OpenApiDefinition) is addressed in commit 8e60618.
The @Metadata annotation now carries label = "security", consistent with the component and endpoint declarations. The catalog regeneration in the same commit (openApi.json, camelYamlDsl-model.json) puts the attribute in the security group, matching the generated configurer classes for the component and endpoint. The open review thread is resolved by this commit.
All prior security findings — YAML alias expansion, nested-reference resolution against the containing document, OpenAPI 3.1 $id chain propagation, fail-closed behaviour on unreadable documents — are addressed and confirmed by davsclaus's re-review. LGTM on the security model.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
davsclaus
left a comment
There was a problem hiding this comment.
Re-review of 47ac40a..8e60618. Thanks Andrea.
The new commit adds label = "security" to externalReferences on OpenApiDefinition, and the generated files are in sync: the core-model and catalog openApi.json, and both copies of camelYamlDsl-model.json. None of the other generated artefacts (XSDs, camelYamlDsl.json, ModelDeserializers) carry labels, so nothing else needs regenerating. The REST DSL attribute now sits in the security group, like the endpoint and component options.
As I said in my last review, I'd like to go over a couple of remaining cases with you directly before approving.
This review was generated by an AI agent (Claude Code on behalf of davsclaus) and may contain inaccuracies. Please verify all suggestions before applying.
luigidemasi
left a comment
There was a problem hiding this comment.
Request changes on 8e60618a6883f0b0657346c36278b692bcf1a8c7: one reference-policy issue remains.
The earlier YAML-alias, ordinary nested-reference, unreadable-document and file: cases now reject prohibited references in both loading paths, and the generated catalog mirrors are synchronized. The latest commit correctly adds the REST DSL security label. The direct OpenAPI 3.1 $id case is fixed, but its inherited base is still lost when the checker follows an external schema; the inline comment describes the remaining reproduction.
Validation:
- At
47ac40a0, both complete module suites passed: 211 camel-rest-openapi tests and 105 camel-openapi-java tests, with no failures, errors or skips. - Verified that both component trees and their dependency configuration are unchanged at
8e60618a; only the model label and generated metadata changed. The full module suites were not rerun for that metadata-only commit. - Reran the additional inherited-
$idregression against the unchanged runtime code. Both endpoint loading and api-doc generation accepted the contract underexternalReferences=localand made one prohibited HTTP request; both regression cases failed their zero-request/rejection assertions. - Hosted Java 21/25 builds and documentation validation are still queued. License check, dependency review and PR-id upload passed; Sonar was skipped.
AI-generated review by Codex on behalf of Luigi De Masi (@luigidemasi).
… across a reference edge The parser keeps the $ids of the schemas enclosing a reference when it follows that reference to another document, so an absolute $id decides what the relative references inside that document resolve to. The check now carries those $ids into the referenced document, folds its base from them the way the parser does, and keys the visited documents by location and inherited $ids. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Previous findings are all addressed. LGTM.
The new commit correctly implements inherited $id propagation across reference edges: the Target class carries inheritedIds into each referenced document, document() folds them into the effective base the same way OpenAPI31Traverser.traverseSchema does, and scan() accumulates $id entries with defensive copies so sibling branches don't share state. The checked set is keyed by location + " under " + inheritedIds, which prevents both duplicate work and incorrect cache hits from the same file reached under different inherited bases. Both checker copies (camel-rest-openapi and camel-openapi-java) are in sync. The test coverage — WireMock assertions of zero HTTP requests, the classpath bridge case in camel-openapi-java, and the all-mode regression — covers the exact scenarios described in the PR body and in luigidemasi's reproduction.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
davsclaus
left a comment
There was a problem hiding this comment.
Re-review of 8e60618..2b81d2f. Thanks Andrea.
The new commit carries the $ids of the schemas enclosing a reference into the document it leads to, builds that document's base from them the way OpenAPI31Traverser.traverseSchema / ReferenceVisitor.resolveSchemaRef do, and keys the visited documents by location plus inherited $ids. Both copies of OpenApiExternalReferences are still identical apart from the package and the class comment. The tests cover it in both modules: localKeepsTheInheritedIdAcrossAnExternalReference with zero requests and the all control in camel-rest-openapi, and keepsTheInheritedIdAcrossAnExternalReference with a classpath bridge in camel-openapi-java.
As in my last reviews, there are still a couple of cases I'd like to go over with you directly before approving.
This review was generated by an AI agent (Claude Code on behalf of davsclaus) and may contain inaccuracies. Please verify all suggestions before applying.
luigidemasi
left a comment
There was a problem hiding this comment.
Request changes on 2b81d2f59eee65f5948cd5b6108472b93b73f80f.
The inherited-$id bypass from my previous review is fixed: both loading paths now reject that reproduction without making an HTTP request. However, the new visited key introduces unbounded traversal for recursive local schemas. Please change cycle detection in both copies of OpenApiExternalReferences and add regression coverage before merging; the inline comment gives the reproduction and required behavior.
Validation at this head:
- Both complete module suites passed: 213 camel-rest-openapi tests and 106 camel-openapi-java tests, with no failures, errors or skips.
- A separate recursive-schema probe threw
OutOfMemoryErrorin both endpoint loading and api-doc generation underexternalReferences=local, using a JVM limited to 256 MB. The identical contract succeeds underalland with the previous checker underlocal. - All 34 focused reference-policy tests passed. Inverting the new OpenAPI 3.1 inheritance guard in an isolated copy caused six test failures; the source was restored afterward. The passing suite does not cover the recursive-schema regression.
- Hosted Java 21/25 builds, documentation validation, license check, dependency review and PR-id upload have passed. Sonar was skipped.
AI-generated review by Codex on behalf of Luigi De Masi (@luigidemasi).
| } | ||
|
|
||
| String key() { | ||
| return inheritedIds.isEmpty() ? location : location + " under " + inheritedIds; |
There was a problem hiding this comment.
[P1] Stop revisiting equivalent recursive schemas
Please replace this history-based visited key with cycle detection that terminates for equivalent resolution states while still distinguishing genuinely different inherited bases. Appending the complete inheritedIds list means that revisiting a schema with its own $id produces a new key every time: [id], [id, id], [id, id, id], etc. checked.add(target.key()) never stops the recursion, even though the effective base is unchanged.
For example, let an OpenAPI 3.1 response schema reference file:///tmp/example/node.yaml, containing:
$id: file:///tmp/example/node.yaml
type: object
properties:
next:
$ref: file:///tmp/example/node.yamlBoth RestOpenApiEndpoint.loadSpecificationFrom and RestOpenApiReader.read exhaust a 256 MB heap under externalReferences=local, with the failure reaching Target.key(). The same contract succeeds under all, and under local with the previous checker. This is a regression for a valid recursive local schema.
Apply the code change to both helper copies. Add tests in both modules proving that recursive local schemas finish successfully, and retain coverage ensuring that revisiting the same document under a different inherited base cannot hide a prohibited HTTP reference. The current acyclic inherited-ID tests do not exercise this failure.
AI-generated review by Codex on behalf of Luigi De Masi (@luigidemasi).
CAMEL-25887:
RestOpenApiEndpoint.loadSpecificationFrom()parses the specification withsetResolveFully(true), so swagger-parser loads every external$refwhen the consumer or producer is created: files from the working directory and the classpath, and documents over http(s) when the reference is a URL or the specification itself comes from a URL. The component had no option to restrict this, and the component page did not mention it. The same applies toRestOpenApiReaderin camel-openapi-java, which parses the contract of a contract-first REST DSL withreadContents(String)(resolve on by default) to serve it as api-doc.What
externalReferencesoption on therest-openapiendpoint and component, and on theopenApielement of the REST DSL (OpenApiDefinition, passed to the consumer URI byRestDefinition):all(default, the current behaviour) allows any reference;localallows references to the classpath and the file system only; a specification loaded from a URL may then reference no other document at all, because the parser resolves its references against that URL;noneallows only references inside the document.OpenApiExternalReferences), and follows the parser's own rules so that what it allows is what the parser then does:DeserializationUtils.deserializeIntoTree(SnakeYAML, YAML aliases expanded, the parser's alias limits applied), so an alias of a URL is seen as the URL;$refagainst the document that contains it:ExternalRefProcessor.join(document, ref)for OpenAPI 3.0, and for OpenAPI 3.1ReferenceUtils.toBaseURI(resolve(ref, base))wherebaseis the chain of the enclosing$ids asOpenAPI31Traverser.traverseSchemabuilds it (root baselocal, the URI the parser gives a specification without location). The$ids enclosing a reference are carried into the document it leads to, asReferenceVisitor.resolveSchemaRefcarries them, and folded against that document's URI before its own$ids apply, so an absolute$idabove$ref: file:///…/bridge.yamlstill decides whatowner.yamlinside bridge.yaml resolves to. A#…reference stays inside the document, also below an$id, since the parser registers the$idbase before it visits the children;localit reads the documents it allows the way the parser reads them (file:andclasspath:by their path asVisitor.readURIdoes, anything else withRefUtils.readExternalRef(…, RELATIVE, …, null): working directory, then classpath) and checks their references in turn, keyed by the resolved location plus the inherited$ids; a document that cannot be read fails the check;RemoteUrl.urlToString, asreadLocationdoes) and handed toreadContents(content, null, options, location), so the default path is unchanged and the restricted path fetches nothing else.RestOpenApiReaderapplies the option of theopenApielement, or else the setting of therest-openapicomponent (read through bean introspection, since the modules do not depend on each other), socamel.component.rest-openapi.external-references=nonecovers the contract served as api-doc as well.Why not swagger-parser's
setSafelyResolveURLIt is not a "local only" mode: for an OpenAPI 3.0 document
ResolverCache.loadRef()runs the raw reference throughPermittedUrlsChecker.verify(), which rejects relative and file references (multi-file specifications) and only lets through http(s) URLs that resolve to public addresses or are on the allow list; for an OpenAPI 3.1 document onlyReferenceVisitor.readHttp()is gated; and a rejected reference only becomes a parser message, which would need to be told apart from the other messages CAMEL-25747 now logs.Tests
RestOpenApiExternalReferencesTest(camel-rest-openapi, WireMock stands in for every URL so that a test can assert that nothing was fetched):localresolve a classpath reference;nonerejects a reference to another document, in an OpenAPI 3.0 and a 3.1 document, and accepts a self-contained one;localrejects an http reference without a request; finds a remote reference in a referenced document, in a document in a subdirectory (resolved next to the document that references it) and in a document referenced by absolute path; fails when a referenced document cannot be read, where the default lets the parser report it;nonerejects a$refgiven as the alias*#remote,localan ordinary alias, both without a request; the default expands the alias and fetches (one request);localrejects$ref: owner.yamlbelow$id: http://…/schemas/(zero requests) where the default fetches/schemas/owner.yaml(one request); the same across a reference edge,$idabove$ref: file:///…/bridge.yamlwhoseowner.yamlhas a benign sibling (zero requests, and the default fetches it from the$idhost);noneallows#/components/schemas/Ownerbelow that$idand the parser makes no request;localreads afile:reference and rejects the http reference inside it, and allows a clean one;localrejects every external reference (one request for the root, none for the reference), the default resolves them,noneallows a self-contained one;RestOpenApiReaderExternalReferencesTest(camel-openapi-java): the default resolves the referenced document into the api-doc; theopenApielement'snoneand the component's setting both fail the read; the subdirectory,$id, inherited-$id(through aclasspath:///bridge) and alias cases above are rejected (the contracts reference a host that does not exist; the check runs before the parser).The existing tests of both modules pass (213 and 106).
Noticed, not changed
RestOpenApiSupport.getBasePathFromOasDocument()(camel-openapi-java) throwsIllegalArgumentException: URI is not absolutefor a contract without aserversentry, because swagger-parser then adds a server with the url/andURI.create("/").toURL()throws that, not theMalformedURLExceptionthe method catches. CAMEL-24825 fixed the same symptom on the consumer side (RestOpenApiEndpoint), but the api-doc of such a contract still fails. The test contracts here declare a server for that reason; the bug deserves its own issue.Claude Code on behalf of oscerd
🤖 Generated with Claude Code