oscerd opened a new pull request, #29212: URL: https://github.com/apache/camel/pull/29212
Fixes [CAMEL-26275](https://issues.apache.org/jira/browse/CAMEL-26275), found while adding the catalog body types (CAMEL-24961). ## 1. The CamelKeycloakOperation header overrides the operation only with allowOperationHeader=true **Was:** the producer took the operation from the `CamelKeycloakOperation` header whenever the header was set, over the `operation` of the endpoint. A message with the header turned an endpoint configured for `getUser` into one that runs, for example, `deleteRealm` with the admin client of the endpoint. **Now:** a new `allowOperationHeader` option, disabled by default as in camel-spiffe, decides whether the header may override the operation. By default the endpoint runs its configured `operation` and ignores the header. With `allowOperationHeader=true`, on the endpoint or on the component (`camel.component.keycloak.allowOperationHeader=true`), the header takes the place of the operation for one message, as before. An endpoint without an `operation` fails with an `IllegalArgumentException` whose message now names both ways to give one, the `operation` option or `allowOperationHeader=true` with the header. The option has the `producer,security` label and the `insecure:dev` security marker with `insecureValue = "true"`, as `allowQueryFromHeader` of camel-sql and `allowDatabaseAndTableFromHeaders` of camel-clickhouse. Its description, and the one of the header, follow camel-spiffe. ## Tests `KeycloakProducerOperationHeaderTest` (6 tests, JUnit assertions as in the rest of the module) runs the producer with a mocked admin client: - the header, as an enum or as text, is ignored by default: a `getUser` endpoint reads the user and does not delete the realm; - an endpoint without an `operation` does not take it from the header by default, and fails with a message that names `allowOperationHeader`; - with `allowOperationHeader=true` the header picks `deleteRealm`, and without the header the endpoint runs its own operation; - the option set on the component, as `camel.component.keycloak.allowOperationHeader=true` does, applies to a new endpoint. Without the change, 6 of 6 fail. 3 fail on their assertions: the header turned the `getUser` endpoint into `deleteRealm`, and an endpoint without an operation took it from the header. The 3 that set the option fail because the option does not exist yet. Module: 167 tests, 0 failures. The integration tests, which need a Keycloak server, were not run. ## Docs and generated files - `keycloak-producer.adoc`: a new "Choosing the operation with a header" section, and its catalog copy. - The description of the `CamelKeycloakOperation` header, and the Javadoc of the `operation` option, say that the header needs `allowOperationHeader=true`. - The body type of the producer output has `dependsOn = "allowOperationHeader"`, as in camel-spiffe: with the option set, the header may pick another operation, so the body is not known from the options of the endpoint. Its description says that the header sets the operation only with `allowOperationHeader=true`. See "Not changed" for what this means for the tooling. - Regenerated: the endpoint and component configurers, the URI factory, `keycloak.json` and its catalog copy, the endpoint DSL and component DSL builders, and `SecurityUtils`, where the `allowOperationHeader` security option now also belongs to the `keycloak` component. - Upgrade guide 4.24: a route that picks the operation with the header must set `allowOperationHeader=true`, and an endpoint without an `operation` that relied on the header now fails unless it sets the option. ## Not changed - The other headers of the producer, such as `CamelKeycloakRealmName` and `CamelKeycloakUserId`, are still read per message: they are the parameters of the operation, as the producer documentation describes. - No list of operations that the header may choose: the option is all or nothing, as in camel-spiffe. - The label is `producer,security` rather than the `security` of camel-spiffe, because the keycloak component also has a consumer and the option only applies to the producer. Both end up in the `security` group of the catalog. - Open question for the reviewers: the `dependsOn = "allowOperationHeader"` on the producer output body type follows camel-spiffe, and it has the same side effect there. `allowOperationHeader` is also an option of the component, so the body-type tooling, such as the YAML validator, treats it as possibly set elsewhere. The output of a `keycloak` producer is then unknown to the tooling in every case, even with `operation=getUser` and the option left at its default. Before, the tooling gave the body of the configured operation. Without the `dependsOn`, it would keep doing so, and would be wrong only for an endpoint that sets `allowOperationHeader=true`. Removing it is a one-line change if that trade-off is preferred. Main only, as the other fixes of the CAMEL-24961 follow-ups. _Claude Code on behalf of Andrea Cosentino (oscerd)_ 🤖 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]
