oscerd commented on issue #3014: URL: https://github.com/apache/camel-kamelets/issues/3014#issuecomment-5792455705
Correcting my previous comment again. I said three of the four authentication types were reachable by adding scalar properties only. **They are not, and the obstacle is the same for all of them.** `userName` and `password` are declared `required` in every one of the six Kamelets: ``` salesforce-composite-upsert-sink required: sObjectName, sObjectIdName, clientId, clientSecret, userName, password salesforce-create-sink required: clientId, clientSecret, userName, password salesforce-delete-sink required: clientId, clientSecret, userName, password salesforce-pubsub-source required: topic, clientId, clientSecret, userName, password salesforce-source required: query, topicName, clientId, clientSecret, userName, password salesforce-update-sink required: clientId, clientSecret, userName, password ``` `CLIENT_CREDENTIALS` uses neither, and `REFRESH_TOKEN` uses neither. So supporting any type beyond `USERNAME_PASSWORD` means moving both out of `required`, in all six. There is no conditional-required in the JSON schema these definitions use, so it cannot be made to depend on the selected type. That is a relaxation of the contract rather than an addition to it. Existing bindings keep working, since they already supply both, but tooling that today refuses a binding without a username would stop refusing it, and the schema would no longer express that username and password go together. Per the reviewer checklist in `CLAUDE.md`, widening a template's contract wants an upgrade-guide entry and PMC review, so it is not something to slip in as part of adding properties. So the shape of this issue is different from how I described it twice above. It is not "blocked only on the keystore decision", and it is not "three quarters deliverable without a decision". **All of it depends on one call: whether these six Kamelets should stop requiring a username and password.** Once that is answered, `authenticationType`, `refreshToken` and `instanceUrl` are mechanical, and `keystore` remains a separate choice on top for JWT. I stopped short of implementing on purpose. Happy to do it as soon as the relaxation is agreed. --- _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]
