Library does not decode unpadded base64
Closed this issue · 3 comments
Decoding eyJuYW1lIjoiSm9obiBEb2UifQ does not work because the validation checks if the length is %4.
Since the string is unpadded (which seems to be optional - haven't read the spec) the library fails to decode the string.
Passing it through
https://base64.guru/tools/repair
reveals the padded value which is decodable.
eyJuYW1lIjoiSm9obiBEb2UifQ==
I assume the library should either pad the value or handle non %4 length inputs.
Hi @cleanerx, thanks for submitting the issue.
This library was intended to just provide encoding/decoding of valid Base64 strings. Although fixing the string eyJuYW1lIjoiSm9obiBEb2UifQ with padding is quite trivial, it's not really considered "valid" base64 for the missing padding.
I'm not going to close this yet, as I do want to see what other libraries currently do with said string. I'm happy to reproduce behaviour in OpenSSL, so I'll spend some time seeing how they handle invalid padded strings there.
@cleanerx OpenSSL also fails to decode the string you mentioned: https://godbolt.org/z/sKebhj4h5 (uncomment the padding and you can see it works).
Although I'm not a massive fan of changing the behaviour of the public API and doing things the user may not expect, I'll add some tasks here to provide this extra functionality to the library. I figured that, even though OpenSSL and other libs don't do this, it may be expected from users for the library to pad these base64 strings.
Closed with #90