vignesh-manel opened a new pull request, #28691: URL: https://github.com/apache/camel/pull/28691
# Description Fixes [CAMEL-26162](https://issues.apache.org/jira/browse/CAMEL-26162). `AuthClientForIntegration` gets the access token that every workday call needs. It had two bugs. 1. **The Basic header of the token request was malformed.** It was `"Basic " + Arrays.toString(Base64.getEncoder().encode(...))`, which gives the byte values (`Basic [89, 50, 120, ...]`), not the Base64 text, so the token request could not succeed. This is a regression from the HttpComponents 5 upgrade (c33a140, CAMEL-18995, 2023), which replaced `new String(...)` with `Arrays.toString(...)`. Every 4.x release is affected. It is now `Base64.getEncoder().encodeToString(... .getBytes(StandardCharsets.UTF_8))`. 2. **The access token was cut from the response at fixed offsets** (`indexOf("access_token") + 16` to `length() - 3`). That only works for one exact layout: in a scratch run `{"access_token":"TOK"}` gave `O`, and `{"access_token": "TOK", "token_type": "Bearer"}` gave `TOK", "token_type": "Beare`. A response that only contained the text `access_token` somewhere was also accepted. The response is now parsed as JSON and the `access_token` string field is used; a response without it fails with the same `No valid access token response.` as before. A correction to the ticket: it proposes Jackson "already on the classpath", but it is not a dependency of camel-workday (the compile tree is httpclient5 + camel-support). I used `camel-util-json` (`Jsoner`), which `camel-http`'s `OAuth2ClientConfigurer` already uses for the same job. It is declared explicitly in the pom (it was already there transitively through camel-support). The response is also decoded as UTF-8 instead of the platform charset. Tests: the new `AuthClientForIntegrationTest` uses a small `CloseableHttpClient` that records the token request and answers it. That fake is needed because the token URL is fixed to `https://<host>/ccx/oauth2/<tenant>/token`. The test checks: - the URL, the `Authorization: Basic <base64 of clientId:clientSecret>` header (the expected value was checked with `base64`), and the form body; - a pretty-printed response with more fields; - the rejection of an error response, of non-JSON and of an empty response. All 3 tests failed before the fix. With only the parsing fixed, the header assertion fails on its own with `Basic [89, 50, 120, ...]`. No upgrade-guide entry: obtaining a token did not work before, so there is nothing to migrate. No other `Arrays.toString(Base64...)` exists in the code base. Local: `mvn clean install -Psourcecheck` in `components/camel-workday`, 13 tests, 0 failures; no generated files changed. _Claude Code on behalf of vignesh-manel_ # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [x] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (Run in the module with `-Psourcecheck`, not from the root; no generated files changed. CI checks the rest.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. 🤖 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]
