allthingssecurity opened a new pull request, #27595: URL: https://github.com/apache/camel/pull/27595
# Description [CAMEL-25483](https://issues.apache.org/jira/browse/CAMEL-25483) Hardening of camel-rest-postman (CAMEL-24367), which is on `main` only and not in any release yet (4.23.0 is unreleased). `PostmanVariableResolver` resolves a `{{name}}` that neither the collection nor the `variables` option defines from Camel properties. It already refuses the `prefix:value` function syntax (`{{env:X}}`, `{{sys:X}}`, vault functions), and the component page explains why: a cloud-hosted collection can be edited by anyone with access to the Postman workspace, and its content should not be able to copy an environment variable into an outgoing request. A plain name gets around that. The properties component's default environment-variable and system-property modes are `OVERRIDE`, so `{{DB_PASSWORD}}` resolves an OS environment variable, `{{some.prop}}` a JVM system property, and any name an application property. The mapper puts the resolved values into outgoing headers, query, URL and body. A collection fetched over HTTP has the same exposure through whoever serves it. A second path: the collection's `Accept` and `Content-Type` header values were not substituted at all. They went verbatim into the delegate `rest:` endpoint URI as `consumes`/`produces`, and `CamelContext.getEndpoint` resolves property placeholders there, functions included. On `main`, `Accept: {{sys:some.prop}}` in a classpath collection is sent as the property's value. This change: - New option `resolveVariablesFromProperties` (`Boolean`, label `common,security`). When not set, Camel properties are consulted only for a collection read from the classpath or the file system (`classpath:`, `file:` or no scheme). A collection from the Postman cloud, `http:`/`https:` or any other resource scheme does not consult them. `true` enables the lookup for any source, `false` disables it for local collections too. The decision is `PostmanCollectionLoader.isLocalSource(source, sourceType)` (new public static method), made once per endpoint when the requests are mapped. Nothing changes per message. - `Accept` and `Content-Type` from the collection are substituted like the other header values, and `RestPostmanEndpoint.buildDelegateUri` fails when the delegate URI still contains `{{`, so producer creation fails instead of reading Camel properties. On `main` an unresolved plain name there already failed (`Property with key [x] not found`), so the visible change is a clearer message and the function and resolvable cases. The message runs the URI through `URISupport.sanitizeUri`. - The `prefix:value` refusal is kept for every source. - `PostmanRequestMapper` takes a new `boolean resolveVariablesFromProperties` constructor argument. The class is in the unreleased component's `support` package and is only built by the endpoint. When the lookup is off, the resolver gets a `null` `CamelContext`, which the resolver already treated as "no properties" (the constructor javadoc now says so). - Docs: the Variables section of the component page says which sources read Camel properties, shows how to pass a property to a remote collection explicitly (`variable.apiToken={{petstore.token}}` in the endpoint URI, resolved by the route author's own configuration), and notes the Accept/Content-Type failure. The resolver javadoc no longer claims that properties can override collection variables (they are consulted last). - Regenerated: component JSON, configurers, URI factory, the catalog copies, `RestPostmanEndpointBuilderFactory` and `RestPostmanComponentBuilderFactory`. No upgrade-guide entry, because the component has not been released. The generated metadata shows `Default: false` for the new option, which is what the tooling writes for any `java.lang.Boolean` (camel-docling's `doOcr` gets the same). The description says what "not set" means. I did not add a `security = "insecure:..."` marker: none of the categories fits, and `true` is the default behaviour for local collections. Tests: new `RestPostmanPropertyFallbackTest` (WireMock serves the collection both as a cloud envelope and as a plain HTTP resource, and stands in for the target API; a Camel property and a JVM system property are set): - cloud collection and HTTP collection: `X-Leak: {{leakProbe}}` and `X-Leak-Sys: {{restPostmanSysLeakProbe}}` are sent unresolved, while the collection variable (`X-Tenant`) and the `variables` option (`X-Region`) still resolve. On `main` both fail: the API receives `from-camel-properties` and `from-system-property`. - classpath collection with `resolveVariablesFromProperties=false`: not resolved (fails on `main`). - classpath collection by default, cloud collection with `resolveVariablesFromProperties=true`, and properties passed as `variable.x={{x}}` in the endpoint URI: resolved. These pass on `main` too. They pin the local default, the opt-in and the documented workaround. - `Accept: {{format}}` from a collection variable is sent as `application/json` (on `main`, producer creation fails with `Property with key [format] not found`). - `Accept: {{sys:restPostmanSysLeakProbe}}` in a classpath collection makes producer creation fail, and no request reaches the API (on `main` the API receives the system property's value). - `PostmanCollectionLoaderTest`: `isLocalSource` for classpath, file, scheme-less, cloud uid, http(s), `ref:`, `mem:` and an explicit `collectionSourceType`. camel-rest-postman: 191 tests pass (`install`, with formatter and import-sort). `PlatformHttpRestPostmanConsumerTest` in camel-platform-http-vertx passes (9). No open pull request touches camel-rest-postman. The branch merges cleanly with current `main`. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-rest-postman, including the formatter and import-sort plugins, copied its JSON and docs to the catalog, and regenerated the endpoint and component DSL with the `generate-endpoint-dsl` and `generate-component-dsl` generators. Only the two RestPostman factories changed. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
