oscerd opened a new pull request, #29209: URL: https://github.com/apache/camel/pull/29209
Fixes [CAMEL-26256](https://issues.apache.org/jira/browse/CAMEL-26256), found while adding the catalog body types (CAMEL-24961). ## 1. A 401 retries once, and only when a new token can be obtained **Was:** on a 401 from Conjur, `ConjurClientImpl.retrieveSecret` and `createSecret` called `authenticate()` and then themselves again, without a limit. With only an `authToken`, `authenticate()` returns the same token, so an expired or wrong token made the client send the same request again and again until a `StackOverflowError`. With an API key or a password, a token that Conjur kept rejecting looped the same way, with a login before each attempt. **Now:** on a 401, the client authenticates again and retries the call once, and only when it has an API key or a password to get a new token with. A client that only has a pre-authenticated token fails with the 401 response at once, and a retry that gets a 401 again fails with it too. The error is the existing `Failed to retrieve secret: HTTP 401 - ...` (or `Failed to create/update secret: ...`), wrapped as before. The public methods keep their signatures; the retry flag is on private overloads. The CyberArk Conjur Vault Property Function uses the same client, so it gets the same bound. ## 2. An endpoint without usable credentials fails at start **Was:** `CyberArkVaultEndpoint.doStart` created a client only for an `authToken`, an `apiKey`, or a `username` with a `password`, and left `conjurClient` null otherwise. The component already rejects an endpoint URI with none of these options, but an endpoint with an `apiKey` and no `username` passed that check: it started, and its first message failed with a `NullPointerException` (the login name is null when the client authenticates). An endpoint whose configuration lacked the credentials in another way (for example a `CyberArkVaultEndpoint` built in code) started with no client and failed on its first message with a `NullPointerException` in the producer. **Now:** when the endpoint has no `conjurClient`, `doStart` checks the credentials first and fails with an `IllegalArgumentException` that names the options to set: `authToken`, `username` and `apiKey`, `username` and `password`, or `conjurClient`. The message names the options only, not their values. ## 3. getSecret's SecretValue header is written by a later createSecret Not changed here: CAMEL-26279 removes the `CamelCyberArkVaultSecretValue` header from `getSecret`, which fixes this item too. See "Not changed". ## Tests - `ConjurClientReauthenticationTest` (new) runs the client against a fake Conjur on a JDK `HttpServer`, which answers the queued statuses to the secret requests and then succeeds, so a client that retries more than it should gets the secret instead of the expected failure. For `retrieveSecret` and `createSecret`: - with only a token, a 401 fails at once, with one request and no login; - with an API key (or a password), a 401 logs in again and the retry with the new token succeeds; - when the new token is rejected too, the call fails after two requests and two logins. - `CyberArkVaultEndpointCredentialsTest` (new): an endpoint with an `apiKey` and no `username`, and an endpoint without any credentials, fail at start with the message that names the options (and not the API key); an endpoint with a `username` and an `apiKey` starts and has a client. - Without the change in `src/main`: 6 of the 9 new tests fail, each with `Expected ... to be thrown, but nothing was thrown`. The four 401 tests (only a token, and a new token that is rejected too, for `retrieveSecret` and `createSecret`) get the secret because the client sends the request again until the fake Conjur gives in, and the two start tests start without usable credentials. The 3 that pass are the two tests where the new token is accepted, which the old code handled too, and the start with a username and an API key. - Module: 9 unit tests, 0 failures. The 14 integration tests of the module, which are not changed, also pass against a Conjur container. ## Docs and generated files - `cyberark-vault-component.adoc`: the Authentication Methods section says that the endpoint fails to start without credentials, and that a 401 is retried once after a new login, which a pre-authenticated token cannot do. Catalog copy updated. - No option, header or body type changes: `cyberark-vault.json` and the DSLs do not change. - Upgrade guide entry for 4.24: the start failure, and the 401 handling with only an `authToken`. ## Not changed - Item 3 (a `createSecret` after a `getSecret` in the same exchange stores the `CamelCyberArkVaultSecretValue` header of the `getSecret`) is fixed by CAMEL-26279, which sets the secret only as the body. This PR does not touch the producer, so both PRs apply independently. - The check is in `doStart`, as the issue proposes, and the client creation in `doStart` is unchanged. The component's own check when it creates the endpoint (URL, account, and an `authToken`, `apiKey` or `username` and `password`) is unchanged: it still lets an `apiKey` without a `username` through, and the new check at start catches it. - `authenticate()` still returns the configured token when the client has no API key or password, as it is a public method of `ConjurClient`; the retry no longer calls it in that case. - Backport: `camel-4.22.x` and `camel-4.18.x` have the same code. Item 1 (the unbounded retry) is a crash fix without a new option, so the `ConjurClientImpl` part is worth porting. Item 2 makes an endpoint without usable credentials fail when the context starts instead of on its first message, so it stays on main. Main only for now, as the other fixes of the CAMEL-24961 follow-ups. Item 1 could also go to camel-4.22.x and camel-4.18.x: it fixes a crash and adds no option. _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]
