oscerd opened a new pull request, #3059:
URL: https://github.com/apache/camel-kamelets/pull/3059
Closes #3014. All six Salesforce Kamelets authenticated with username and
password only, while `camel-salesforce` offers four authentication types. This
adds the three that need nothing but scalar properties.
## The obstacle was the old properties, not the new ones
I described this issue two other ways before getting here, and both were
wrong. It is not blocked only on the `keystore` decision, and it is not three
quarters deliverable without one. `userName` and `password` were listed under
`required` in **every one of the six**, and `CLIENT_CREDENTIALS` uses neither —
nor does `REFRESH_TOKEN`. There is no conditional-required in the JSON schema
these definitions use, so supporting any other type means moving both out of
`required` and making their placeholders optional.
Everything else is additive:
| property | purpose |
|---|---|
| `authenticationType` | `USERNAME_PASSWORD`, `CLIENT_CREDENTIALS` or
`REFRESH_TOKEN` |
| `refreshToken` | for `REFRESH_TOKEN`; `format: password` with the
credentials descriptor |
| `instanceUrl` | when the authentication response carries none |
`USERNAME_PASSWORD` remains the default, so an existing binding behaves
exactly as before.
## JWT is deliberately not in the enum
It needs `keystore`, typed `KeyStoreParameters` rather than a scalar, and
how to express that is still open on the issue. Listing `JWT` now would
advertise a type that cannot authenticate — a worse outcome than leaving it out
until the keystore approach is settled.
## This relaxes the contract
Worth stating plainly rather than burying: a binding that omits a username
is no longer rejected, and the schema no longer expresses that username and
password go together. That is the unavoidable price of supporting more than one
authentication type through a schema without conditional requirements. Existing
bindings are unaffected, since they already supply both.
The reviewer checklist in `CLAUDE.md` asks for an upgrade-guide entry on a
relaxation. This repository has no upgrade guide — only `development.adoc`,
`index.adoc` and `security-model.adoc` — so that note belongs in the Camel
guide rather than here.
## Verified
Driving a message into `salesforce-create-sink` with
`authenticationType=CLIENT_CREDENTIALS` and **no** `userName` or `password`,
same driver and arguments against both trees:
```
main IllegalArgumentException: Route template salesforce-create-sink
the following mandatory parameters must be provided: userName,
password
this PR no missing-parameter error at all
```
The branch run does stop later, on an unrelated protobuf class missing from
my local JBang environment, but that happens at component class loading — after
the template parameter validation this change is about. The control against
`main` is what makes the result meaningful rather than the branch run on its
own.
`mvn clean install` green: validator over 262 Kamelets,
`KameletsCatalogTest` 18/18, catalog SBOM unchanged since no dependency moved.
## Not covered
Authentication against a real Salesforce org. There are no Citrus tests for
these Kamelets and CI has no credentials, so what is verified here is that the
template accepts the configuration, not that the flow completes. Someone with
an org should confirm a real `CLIENT_CREDENTIALS` connection before this is
relied on.
---
_Claude Code on behalf of Andrea Cosentino_
--
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]
