Dhairya-007 opened a new pull request, #29711:
URL: https://github.com/apache/camel/pull/29711
## Problem
`HttpServerChannelHandler.extractBasicAuthSubject` reads the Base64-decoded
credentials back with the platform default charset:
```java
String decoded = StringHelper.after(auth, " ");
// the decoded part is base64 encoded, so we need to decode that
ByteBuf buf = NettyConverter.toByteBuffer(decoded.getBytes());
ByteBuf out = Base64.decode(buf);
try {
String userAndPw = out.toString(Charset.defaultCharset());
```
[RFC 7617 §2.1](https://www.rfc-editor.org/rfc/rfc7617#section-2.1) says the
client encodes `user:password` with UTF-8, which is what browsers and Camel's
own producers send. A `netty-http` consumer running on a JVM whose default
charset is not UTF-8 — `-Dfile.encoding`, `file.encoding=COMPAT`, or a JVM
before 18 following the platform locale — therefore reconstructs a
**different** password than the one that was sent, as soon as it contains a
non-ASCII character, and answers 401 although the credentials are correct.
This is the receiving side of what #29694 fixed on the sending side;
@davsclaus spotted it while reviewing that PR.
## Fix
- `out.toString(StandardCharsets.UTF_8)` for the credentials.
- `decoded.getBytes(StandardCharsets.US_ASCII)` for the Base64 text itself,
which is ASCII by definition — byte-identical in any ASCII-compatible charset,
but it was the same unchecked pattern two lines up.
The now-unused `java.nio.charset.Charset` import is dropped.
## Tests
New `HttpServerChannelHandlerBasicAuthTest`, which calls the `protected
static` method directly from the same package:
- `shouldDecodeCredentialsAsUtf8` — the header `Basic dXNlcjpww6Rzc3dvcmQ=`,
which is `user:pässword` encoded as a client sends it, has to come back as
`pässword`. The expected values are written out rather than recomputed from the
input, so the test states what the wire format means instead of agreeing with
the implementation.
- `shouldDecodeAsciiCredentials` — `scott:tiger`, the ordinary case,
unchanged.
- `shouldIgnoreAnotherScheme` — a `Bearer` header yields no principal.
As on #29694: Camel's CI runs Java 21, where the default charset is already
UTF-8, so the first test is green there either way. It fails on a JVM started
with a non-UTF-8 `file.encoding`, and it pins the behaviour from now on.
--
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]
