oscerd opened a new pull request, #29211: URL: https://github.com/apache/camel/pull/29211
Fixes [CAMEL-26274](https://issues.apache.org/jira/browse/CAMEL-26274), found while adding the catalog body types (CAMEL-24961). ## 1. The connection and credential settings come from the endpoint unless allowConnectionAndCredentialsFromHeaders is set **Was:** `DockerClientFactory` took the host, the port, the socket mode, the registry username, password and server address, `secure`, `tlsVerify`, `certPath` and `cmdExecFactory` from the `CamelDockerHost`, `CamelDockerPort`, `CamelDockerSocketEnabled`, `CamelDockerUsername`, `CamelDockerPassword`, `CamelDockerServerAddress`, `CamelDockerSecure`, `CamelDockerTlsVerify`, `CamelDockerCertPath` and `CamelDockerCmdExecFactory` headers whenever they were set, over the options of the endpoint. A message could so point the producer at another Docker daemon, turn TLS to the daemon on or off, pick other client certificates or another `DockerCmdExecFactory` class, or send the registry username and password of the endpoint to another registry. Each different value also created and cached another Docker client. **Now:** these ten settings come from the endpoint configuration only, unless the new `allowConnectionAndCredentialsFromHeaders` option is `true` (default `false`). The option is on `DockerConfiguration`, so it can be set on an endpoint or on the component as the default of all its endpoints, with the endpoint value winning. It has `label = "producer,security"`, `security = "insecure:dev"` and `insecureValue = "true"`, as `allowQueryFromHeader` of camel-sql and `allowDatabaseAndTableFromHeaders` of camel-clickhouse. Only the producers pass the message to `DockerClientFactory`; the `events` and `stats` consumers pass none and always used the endpoint configuration, so the option is a producer option. The other headers, such as `CamelDockerContainerId`, still take precedence over the options, as before. The descriptions of the ten headers say that they are ignored without the option. ## Tests - `DockerClientFactoryTest` (new) sends messages through the producer to a component whose `getClient` is spied, and checks the client profile that the producer asks for: - for each of the ten headers, the profile with the header equals the profile without it by default, and differs with `allowConnectionAndCredentialsFromHeaders=true` on the endpoint; - `imagepush` with all ten headers uses the daemon, the TLS settings, the factory and the registry credentials of the endpoint, and still takes the image name from `CamelDockerName`; - the option set on the component lets the headers choose the daemon and the registry, and an endpoint can turn it off again. - `BaseDockerHeaderTest` now configures the endpoint with the settings of the client profile it registers, so the 35 header test classes run with the default and show that the operation headers still apply. `AuthCmdHeaderTest` and `PushImageCmdHeaderTest`, which send the registry credentials as headers, set the option. - Without the change in `src/main`, 13 of the 23 new tests fail on an assertion: the ten cases of `headerDoesNotChangeTheClientProfileByDefault` (the header changes the profile), `pushUsesTheDaemonAndTheRegistryCredentialsOfTheEndpoint` (the client goes to `unix://other.example.com` instead of `tcp://docker.example.com:2376`), and the two tests that set the option on the component (the component has no such option). The ten that pass are the cases of `headerChangesTheClientProfileWithTheOption`, as the old code always used the headers. The other tests of the module pass with and without the change. - Module: 93 tests, 0 failures, 0 errors, 4 skipped (the disabled `RemoveImageCmdUriTest` and three tests that need a Docker daemon, as before). ## Docs and generated files - `docker-component.adoc`: the Header Strategy section lists the ten headers that need the option, says what it lets a message choose, and suggests `removeHeaders("CamelDocker*")` for messages from untrusted producers. Catalog copy updated. - `docker.json` regenerated (new option on the component and the endpoint, the ten header descriptions), with its catalog copy. - The endpoint and component DSL and `SecurityUtils` gain the new option. - Upgrade guide entry for 4.24: what a route that relies on these headers has to set to keep using them. ## Not changed - `CamelDockerEmail`, `CamelDockerRequestTimeout`, `CamelDockerMaxTotalConnections` and `CamelDockerMaxPerRouteConnections` are also part of the client profile and still come from the headers first, as the issue scopes the change to the connection and credential settings. They do not change the daemon or the registry, but a different value still creates and caches another client. Should they move under the option too? - The option name follows `allowDatabaseAndTableFromHeaders` and names both groups of settings. A shorter name such as `allowConnectionFromHeaders` would leave the registry credentials out of the name. - No backport: the change adds an option and changes a default, so it stays on main. `camel-4.22.x` and `camel-4.18.x` have the same code. Main only, as the other fixes of the CAMEL-24961 follow-ups. _Claude Code on behalf of Andrea Cosentino (oscerd)_ 🤖 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]
