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]

Reply via email to