Use JDK (8+) Base32/64 codecs instead of apache commons
roytmana opened this issue · comments
Would it be possible to switch from apache commons base 32/64 encoding to one provided by JDK (8+)
It would allow to do away with an extra dependency which has potential to clash with other dependencies
or at least make encoding pluggable - an interface for codec and two built in implementations?
You can make it so it can be configurable a specific implementation or use default or use "auto" which looks for java version and fallback on apache codec
I would be happy to write and contribute code for it if you'd like
Thank you,
alex
ouch just realized JDK only has Base64. Still would like to make a pluggable encoder
Yep, IIRC that's where I stumbled when I gave it a shot. I agree that, if the JDK provided all the required classes, it would be nice to drop a dependency. If you wish to contribute a solution, please be welcome. However, this library is so small that it looks like overkill to me.
the problem with it is that it clashes with its other versions brought by other code code which has a "bigger" need for it
Maybe alternative solution is to shade a specific version of apache encoding (does not even need to be the entire jar if only few classes can be picked) into your JAR into your package root and remove this dependency from being external? This will take just a few lines in POM
RANT: In my case it failed miserable because I failed to realize that your library's getTotpPassword expects encoded key as input so I have a bunch of services talking to each other with the help of your libraries using un-encoded pre-agreed keys and it never failed on bad keys. With its latest version, apache's Base32 it much stricter and fails bad bad syntax of the key. So now I need to upgrade them all simultaneously and fix pre-encoding issue simultaneously.
I wish the whole encoding thing was an internal aspect of your library and it would not expect pre-encoded keys and any knowledge of how it needs to be done.