[
https://issues.apache.org/jira/browse/KAFKA-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16333715#comment-16333715
]
Ron Dagostino commented on KAFKA-6464:
--------------------------------------
Please assign to me; I will submit a patch.
> 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
> Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> 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)
