Dhairya-007 opened a new pull request, #29694:
URL: https://github.com/apache/camel/pull/29694
## Problem
Five places build an `Authorization: Basic` (or `Proxy-Authorization:
Basic`) header by Base64-encoding `user:password` through the no-argument
`String.getBytes()`, which uses **the JVM's default charset**:
| component | file |
| --- | --- |
| camel-as2 | `AS2HeaderUtils.addAuthorizationHeader` |
| camel-keycloak | `KeycloakProducer` (token revocation) |
| camel-keycloak | `KeycloakTokenIntrospector` |
| camel-smpp | `SmppConnectionFactory.connectProxy` |
| camel-wordpress | `WordpressBasicAuthentication` |
```java
String auth = clientId + ":" + clientSecret;
String encodedAuth = Base64.getEncoder().encodeToString(auth.getBytes());
request.setHeader("Authorization", "Basic " + encodedAuth);
```
[RFC 7617 §2.1](https://www.rfc-editor.org/rfc/rfc7617#section-2.1) says the
credentials are encoded with UTF-8 unless the server names another charset, and
that is what Keycloak, WordPress and ordinary HTTP proxies expect.
The JVM default is only UTF-8 when nothing overrides it.
`-Dfile.encoding=ISO-8859-1`, `file.encoding=COMPAT`, or any JVM before 18
(which follows the platform locale, so US-ASCII under the `C`/`POSIX` locale
that containers often use) all give something else. A user name or password
containing a non-ASCII character then produces a **different Authorization
header on different machines**, and the server answers 401 although the
credentials are correct. Because the bytes are Base64-encoded, nothing in the
failure points at the encoding — this is the kind of defect that gets debugged
for a day.
## Fix
Pass `StandardCharsets.UTF_8` explicitly in all five places. Credentials
made only of ASCII characters encode to exactly the same bytes as before, so
nothing changes for the common case.
`camel-smpp`'s `connectProxy` also wrote the `CONNECT` request line, the
configured proxy headers and the line separators, and read the proxy's
response, in the default charset. Those are converted too, so the whole
exchange is built one way rather than two.
## Tests
`AS2HeaderUtilsTest.addAuthorizationHeaderEncodesCredentialsAsUtf8` adds a
Basic header for a password with a non-ASCII character and asserts the exact
header value against the Base64 of the UTF-8 bytes. It fails on `main` under
any JVM whose default charset is not UTF-8, and pins the encoding from now on.
The other four call sites are the same one-line change inside methods that
do network I/O (an HTTP POST to Keycloak, a CXF `WebClient` configuration, a
proxy `CONNECT`), so they have no seam to assert on without a server; the
shared behaviour is what the AS2 test covers.
--
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]