Repository navigation
Conversation
…ication credentials to the cluster nodes [CAMEL-25707](https://issues.apache.org/jira/browse/CAMEL-25707): `ElasticsearchRestClientProducer.createClient()` registered the configured `user` and `password` with `AuthScope.ANY`, which matches any host. - The credentials are now held by a `NodeScopedCredentialsProvider`, which offers them only to the nodes the client talks to: the hosts of `hostAddressesList` and, when `enableSniffer` is set, the nodes the sniffer finds. - A node matches on scheme, host name (in any case) and port. A node without a port matches the default port of its scheme. - The provider reads the nodes from the `RestClient` (`getNodes()`) on each lookup, so it follows the nodes the sniffer adds or removes. Every configured node keeps receiving the credentials. - HttpClient 4's `BasicCredentialsProvider` matches an `AuthScope` on host and port only, never on the scheme. The provider therefore checks the origin of the scope that HttpClient looks the credentials up with, both preemptively and after a challenge. - `setCredentials` and `clear` do nothing, because the credentials come from the endpoint configuration only. HttpClient calls `setCredentials` for the user info of a request URI. - A client set with the `restClient` option is not changed. This is the same change as apache#27946 (CAMEL-25706) for camel-elasticsearch. The provider class is duplicated because the two components are separate modules. Closes apache#27949 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit f8bd57d) Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
…ials to the cluster nodes [CAMEL-25708](https://issues.apache.org/jira/browse/CAMEL-25708): `OpensearchProducer.createClient()` registered the configured `user` and `password` with `new AuthScope(null, null, -1, null, null)`, which matches any host. [CAMEL-24815](https://issues.apache.org/jira/browse/CAMEL-24815) switched to it so that every node of a multi-host cluster receives the credentials, not only the first configured host. - The credentials are now held by a `NodeScopedCredentialsProvider`, which offers them only to the nodes the client talks to: the hosts of `hostAddresses` and, when `enableSniffer` is set, the nodes the sniffer finds. Every configured node keeps receiving them, as CAMEL-24815 intended. - A node matches on scheme, host name (in any case) and port. A node without a port matches the default port of its scheme. - The provider reads the nodes from the `RestClient` (`getNodes()`) on each lookup, so it follows the nodes the sniffer adds or removes. - A client set with the `client` or `openSearchClient` option is not changed. This is the same change as apache#27946 (CAMEL-25706) for camel-elasticsearch. Here it is written against HttpClient 5, whose `CredentialsProvider` only looks credentials up, and whose `AuthScope` carries the scheme (`getProtocol()`). Upgrade guide (4.24): a request to another host is sent without the credentials. This includes the host of a node with another scheme or port. Closes apache#27948 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 0048096) Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
…entials to the cluster nodes [CAMEL-25706](https://issues.apache.org/jira/browse/CAMEL-25706): `ElasticsearchProducer.createClient()` registered the configured `user` and `password` with `AuthScope.ANY`, which matches any host. - The credentials are now held by a `NodeScopedCredentialsProvider`, which offers them only to the nodes the client talks to: the hosts of `hostAddresses` and, when `enableSniffer` is set, the nodes the sniffer finds. - A node matches on scheme, host name (in any case) and port. A node without a port matches the default port of its scheme. - The provider reads the nodes from the `RestClient` (`getNodes()`) on each lookup, so it follows the nodes the sniffer adds or removes. Every configured node keeps receiving the credentials. - HttpClient 4's `BasicCredentialsProvider` matches an `AuthScope` on host and port only, never on the scheme. The provider therefore checks the origin of the scope that HttpClient looks the credentials up with, both preemptively and after a challenge. - `setCredentials` and `clear` do nothing, because the credentials come from the endpoint configuration only. HttpClient calls `setCredentials` for the user info of a request URI. - A client set with the `client` option is not changed. Closes apache#27946 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 442e440) Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet-bot
reviewed
Oct 18, 2026
gnodet-bot
left a comment
gnodet-bot
left a comment
Contributor
There was a problem hiding this comment.
LGTM. Clean backport of #27946, #27948, #27949 to camel-4.22.x.
The three NodeScopedCredentialsProvider implementations are correctly adapted to their respective HttpClient versions (HC4 for camel-elasticsearch and camel-elasticsearch-rest-client, HC5 for camel-opensearch). The AtomicReference pattern has a safe null-check fallback for the initialization window. Test coverage is thorough: provider unit tests (matching, rejection, dynamic sniffer nodes, null scopes), producer factory unit tests, and end-to-end integration tests using a real HTTP server for the rest-client and opensearch modules. The camel-elasticsearch module intentionally lacks the end-to-end test, consistent with the original PR on main.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
Contributor
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 11 tested, 29 compile-only — current: 11 all testedMaveniverse Scalpel detected 40 affected modules (current approach: 11).
|
davsclaus
added
backport
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Backport of #27949 (CAMEL-25707), #27948 (CAMEL-25708) and #27946 (CAMEL-25706) to camel-4.22.x. These are straight cherry-picks of the merged commits
f8bd57d57c79,004809689f98and442e440e43e6, in merge order.ElasticsearchProducer,ElasticsearchRestClientProducerandOpensearchProducerare identical to main on this branch, so the picks apply as they are.camel-4x-upgrade-guide-4_24.adochunks are dropped, because the upgrade guides live on main. The 4.22.3 notes are added on main in CAMEL-25706, CAMEL-25707, CAMEL-25708: upgrade guide notes for the 4.22.3 and 4.18.6 backports #28052.Compared with the original PRs, only the upgrade-guide hunks differ.
Tests
mvn clean install -DskipTests -DskipITson this branch: green, no generated-file changes.Claude Code on behalf of oscerd
🤖 Generated with Claude Code