You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Ron Dagostino (JIRA)" <ji...@apache.org> on 2018/01/21 22:39:05 UTC

[jira] [Created] (KAFKA-6464) Base64URL encoding under JRE 1.7 is broken due to incorrect padding assumption

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)