[
https://issues.apache.org/jira/browse/CAMEL-26256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26256:
--------------------------------
Fix Version/s: 4.22.3
4.18.6
> camel-cyberark-vault - with authToken, a 401 makes the client retry with the
> same token until a StackOverflowError, and no credentials gives a
> NullPointerException
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26256
> URL: https://issues.apache.org/jira/browse/CAMEL-26256
> Project: Camel
> Issue Type: Bug
> Reporter: Claus Ibsen
> Assignee: Andrea Cosentino
> Priority: Minor
> Fix For: 4.18.6, 4.22.3, 4.24.0
>
>
> Found while adding the catalog body types of cyberark-vault (CAMEL-24961, PR
> #28404).
> h4. 1. With authToken, a 401 retries without end
> On a 401, {{ConjurClientImpl.retrieveSecret}} (main 2a465aa4814c, lines
> 97-101) calls {{authenticate()}} and then itself again; with only an
> {{authToken}} configured, {{authenticate()}} (lines 125-127) returns the same
> token, so an expired or wrong token recurses until a {{StackOverflowError}}.
> {{createSecret}} has the same pattern (lines 185-189). Read in the code, not
> run.
> Proposed: retry once only, and fail with the 401 when there is no way to get
> a new token.
> h4. 2. No credentials gives a NullPointerException
> {{CyberArkVaultEndpoint.doStart}} (lines 78-84) leaves {{conjurClient}} null
> when no authToken, apiKey or username/password is set, and the producer then
> fails with a NullPointerException on the first call. Checked on
> 4.24.0-SNAPSHOT with Conjur and Postgres (test-infra docker).
> Proposed: fail at endpoint start with a message that names the options to set.
> h4. 3. getSecret's SecretValue header is written by a later createSecret
> {{CyberArkVaultProducer}} getSecret sets the
> {{CamelCyberArkVaultSecretValue}} header (line 70), and createSecret prefers
> that header over the body (line 76), so getSecret then createSecret in the
> same exchange writes the value read earlier instead of the new body. Checked
> on 4.24.0-SNAPSHOT with Conjur.
> Proposed: do not set the value header on getSecret (the body has it), or have
> createSecret prefer the body.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)