davsclaus opened a new pull request, #29283: URL: https://github.com/apache/camel/pull/29283
Fixes [CAMEL-26551](https://issues.apache.org/jira/browse/CAMEL-26551). Follows the pattern of CAMEL-26273 (camel-clickhouse, `allowDatabaseAndTableFromHeaders`). ## What was wrong For the `secret` operation, `DaprConfigurationOptionsProxy.getSecretStore` and `getKey` took the `CamelDaprSecretStore` and `CamelDaprKey` headers first, and the `secretStore` and `key` options of the endpoint only when no header was set. A message could so read another secret, or use another secret store, than the endpoint is configured with. There was no option to turn that off. ## What changed - New endpoint (and component) option `allowSecretStoreAndKeyFromHeaders` (default `false`, label `producer,security`, `security = "insecure:dev"`, registered in `SecurityUtils` like the other `allow*FromHeaders` options). - With the default, the `secret` operation uses only the `secretStore` and `key` options of the endpoint. With `allowSecretStoreAndKeyFromHeaders=true`, the two headers override them as before. - A `secret` endpoint without a `key` reads all the secrets of the store. When the message has a `CamelDaprKey` header that is now ignored, it fails with an error that names the option, instead of silently returning all the secrets (a different body type than the single secret the route expected). - A `secret` endpoint without a `secretStore` fails as before ("secretStore is mandatory"); when the message has a `CamelDaprSecretStore` header, the error also says the header is ignored unless the option is set. - The `state` operations are not changed: they still take the key from `CamelDaprKey` (new `getSecretKey` in the proxy; `getKey` is unchanged). - The header descriptions of `CamelDaprSecretStore` and `CamelDaprKey` mention the option. ## Tests - `DaprProducerTest`: headers ignored by default (single secret), key header on a bulk endpoint fails without calling Dapr, secret store header does not stand in for a missing `secretStore`, headers override the endpoint when allowed. - `DaprConfigurationOptionsProxyTest`: the secret lookups follow the option, `getKey` (state) still uses the header. - The four "by default" tests fail without the fix. Module: 87 tests, all pass (`mvn clean install -Psourcecheck`). ## Docs and generated files - `dapr-component.adoc`: the secret operation section describes the option, and a new "Headers that override the endpoint" section lists which headers take the place of endpoint options, and suggests `removeHeaders("CamelDapr*")`. - Upgrade guide 4.24: new `camel-dapr` entry next to the existing CAMEL-26263 one. - Regenerated: configurers, URI factory, `dapr.json`, catalog copies (json + adoc), endpoint and component DSL, `SecurityUtils`. ## Not changed - The other operations also take their target from headers first (`CamelDaprStateStore`, `CamelDaprConfigStore`, `CamelDaprPubSubName`/`CamelDaprTopic`, `CamelDaprBindingName`/`CamelDaprBindingOperation`, `CamelDaprServiceToInvoke`/`CamelDaprMethodToInvoke`, `CamelDaprStoreName`/`CamelDaprResourceId`, the workflow headers). They are out of the scope of this issue and are now listed on the component page. - `CamelDaprMetadata` is still passed to the secret request. There is no endpoint option for metadata, so gating it would remove the only way to set it. _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 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]
