oscerd opened a new pull request, #27716: URL: https://github.com/apache/camel/pull/27716
## Description [CAMEL-25564](https://issues.apache.org/jira/browse/CAMEL-25564) In webhook mode, camel-telegram registered the webhook with the `url` parameter only. The Bot API's `setWebhook` also accepts a `secret_token`, which Telegram sends back in the `X-Telegram-Bot-Api-Secret-Token` header of every webhook request. This PR uses it: - New endpoint option `webhookSecretToken` (label `consumer,security`, marked as a secret). When it is not set, the token is derived from the authorization token: HMAC-SHA256, base64url without padding, so 43 characters from the set Telegram allows. A derived value, rather than a random one, stays the same across restarts and across replicas that serve the same webhook URL. It also lets the two sides of the `WebhookRoutePolicy` flow (a registration run and the serving instances, both with `webhookAutoRegister=false`) agree on the token without extra configuration. A configured value is checked against Telegram's rules: 1 to 256 characters, only `A-Z`, `a-z`, `0-9`, `_` and `-`. - `TelegramEndpoint.registerWebhook()` passes the token to `setWebhook`, through a new `TelegramService.setWebhook(url, secretToken)` overload. The existing one-argument method is kept. - `TelegramWebhookProcessor` compares the header with the token in constant time, before it parses the body. A request without the header, or with a different value, gets HTTP 403, is logged at WARN, and does not reach the route. Once checked, the header is removed from the message, so the token is not passed on to the route. - Docs: the webhook mode section of the component page, and upgrade-guide notes for 4.24 (new page), 4.22.2 and 4.18.6. The backports to `camel-4.22.x` and `camel-4.18.x` will follow once this is merged. ### Behaviour change When Camel registers the webhook, nothing changes for users: that is the case at startup with the default `webhookAutoRegister=true`, and through the `WebhookRoutePolicy`. If the webhook is registered outside Camel, `webhookSecretToken` must be set and passed as `secret_token`. A client that calls the webhook endpoint directly must send the header. That includes two downstream tests, which will need a small update when they pick this change up: `TelegramWebhookCallTest` in camel-spring-boot (`camel-telegram-starter`), and the webhook test of the camel-quarkus telegram integration tests. ## Tests - `TelegramWebhookCallTest`: a request is accepted with the derived token and with a configured token, and the route does not see the header. A request without the header, or with a wrong value, gets 403, and the route is not invoked. - `TelegramWebhookSecretTokenTest`: the derived token is stable, differs for another authorization token and uses only the allowed characters. An invalid configured token is refused. Registration sends the derived token, or the configured one, as `secret_token`; this is checked against a mock Telegram API. - `camel-telegram`: 100 tests, 0 failures (1 skipped, as before). - Full reactor `mvn clean install -DskipTests -DskipITs`: green; the regenerated files are included. _Claude Code on behalf of 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]
