Ron Dagostino created KAFKA-6464:
------------------------------------
Summary: Base64URL encoding under JRE 1.7 is broken due to
incorrect padding assumption
Key: KAFKA-6464
URL: https://issues.apache.org/jira/browse/KAFKA-6464
Project: Kafka
Issue Type: Bug
Components: clients
Affects Versions: 1.0.0
Reporter: Ron Dagostino
The org.apache.kafka.common.utils.Base64 class defers Base64 encoding/decoding
to the java.util.Base64 class beginning with JRE 1.8 but leverages
javax.xml.bind.DatatypeConverter under JRE 1.7. The implementation of the
encodeToString(bytes[]) method returned under JRE 1.7 by
Base64.urlEncoderNoPadding() blindly removes the last two trailing characters
of the Base64 encoding under the assumption that they will always be the string
"==" but that is incorrect; padding can be "=", "==", or non-existent.
For example, this statement:
{code:java}
Base64.urlEncoderNoPadding().encodeToString(
"{\"alg\":\"none\"}".getBytes(StandardCharsets.UTF_8));{code}
Yields this, which is incorrect: (because the padding on the Base64 encoded
value is "=" instead of the assumed "==", so an extra character is incorrectly
trimmed):
{{eyJhbGciOiJub25lIn}}
The correct value is:
{{eyJhbGciOiJub25lIn0}}
There is also no Base64.urlDecoder() method, which aside from providing useful
functionality would also make it easy to write a unit test (there currently is
none).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
