Hi cblown
I think I might know what's going on here, but please correct me if I've got something wrong:
Base64 encoding was designed to encode binary data into an ASCII string (a radix-64 representation). The string "12345678901234567890" is not a base-64-encoded string, so decoding it using base64 will not necessarily generate the same result on different implementations of the Base64 spec (since the spec says nothing about this). Try any number of online Base64 decoding tools and try decoding the string "12345678901234567890" -- you will either get different results in different tools, or you may get an error (because this is not a valid use of Base64 decoding).
If you encode the string "12345678901234567890" using base64, you will get the same results in the Lithium's Freemarker context implementation that you get in any other valid Base64 encoding algorithm (for UTF-8 charset you would get "MTIzNDU2Nzg5MDEyMzQ1Njc4OTA="). If you then decode the base-64 encoded string (in this case "MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=") you will get the same result on in Lithium's Freemarker context implementation that will get in any other valid Base64 decoding algorithm (for UTF-8 charset you would get "12345678901234567890").
Why is the 3rd party auth system trying to decode the string "12345678901234567890" (which isn't a base-64 encoded string), and can that be changed? (because it's not going to behave correctly on different implementations of Base64).
-Doug
This answer is misleading.
The problem is that base64.encode and digest.hmac take only strings as input.
Most Base64 suites take a binary array. Like Spring:
Why Base64 encode a binary array that will not encode to a string? It increases the entropy of the result.
cblown Please support the following Product Idea to add versions of the methods base64.encode and digest.hmac that take byte arrays as input:
