Claus Ibsen created CAMEL-26256:
-----------------------------------

             Summary: 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
             Fix For: 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)

Reply via email to