diesk_at_fast.fujitsu.com.au wrote on 06/20/2011 07:31 PM:
> Hi,
>
> I've encountered an issue with an API I'm using that depends on a
> base64 encoded authentication string. It uses JavaMail's base64
> encoding through MimeUtils.java.
>
> When I have the same JavaMail version that is used on the server in my
> client's classpath it works fine, but when I use a later version on the
> client it seems the base64 encoded data computed on the server doesn't
> match the encoded data on the client so the authentication fails.
>
> I'm trying to understand why the encoding algorithm was changed.
>
> The JavaMail version that works is v1.4 (classes' timestamp 2 May 2006)
> and any version in GlassFish v2 and higher I tried (JavaMail v1.4.1 and
> up) fails.
> I suspect the extra newline ("\r\n") that was added to
> BASE64EncoderStream#close() is the culprit.
>
> From what I understand of Base64 encoding (RFC2045) adding a newline is
> not invalid because decoders must ignore line breaks and characters not
> in the Base64 alphabet. But why was the newline added?
This might've been this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6629213
although that was only fixed in 1.4.2. If not that exact bug, then
most likely some bug like that.
In any event, these stream encoding/decoding methods weren't intended
for use with authentication strings. All the JavaMail code that needs
to do such encoding uses the com.sun.mail.util.BASE64EncoderStream
class directly. Yes, that's non-spec-defined implementation class, sorry.
You can use it, but you accept the risk of incompatible changes and
non-portability.
Perhaps we should expose simple encode/decode methods that work on short
strings and don't add whitespace? I keep hoping that the JDK will add
such methods...