[
https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys...
]
Farah Juma commented on ELY-43:
-------------------------------
Took a look at the FlexBase64 implementation. We could replace the existing Base64
implementation with this one but we'd need to make at least the following
modifications to it:
\\
\\
* Add support for the bcrypt and modular crypt alphabets (it currently supports the
standard Base64 alphabet and a URL-safe variant of Base64)
* Add methods for encoding/decoding with an interleave table using the modular crypt style
little-endian scheme
* Add methods for encoding/decoding a single byte
* Add a method for decoding an encoded character array
To get an idea of how this would change usage, consider the following examples:
1) Using the Base64 implementation, encoding a byte array, {{src}}, using the bcrypt
alphabet and appending the result to a StringBuilder, {{b}}, is currently done like this:
{code}Base64.base64EncodeBCrypt(b, new ByteArrayInputStream(src));{code}
With a modified version of {{FlexBase64}}, the above might be done like this:
{code}b.append(FlexBase64.encodeString(src, false, FlexBase64.BCRYPT));{code}
2) Using the Base64 implementation, decoding a character array, {{encoded}}, into a byte
array, {{bytes}}, using the standard alphabet, is currently done like this:
{code}byte[] bytes = Base64.base64DecodeStandard(encoded, 0){code}
With a modified version of {{FlexBase64}}, the above might look like this:
{code}
ByteBuffer b = FlexBase64.decode(encoded, 0, encoded.length, FlexBase64.STANDARD);
byte[] bytes = new byte[b.limit()];
b.get(bytes)
{code}
Any thoughts on this?
Clean up Base64
---------------
Key: ELY-43
URL:
https://issues.jboss.org/browse/ELY-43
Project: WildFly Elytron
Issue Type: Feature Request
Components: Utils
Reporter: Darran Lofthouse
Assignee: Farah Juma
Fix For: 1.0.0.Beta1
The Base64 implementation has been split out of PasswordUtils some additional steps are
needed to finish cleaning it up: -
- Look at switching to input and output streams instead of the custom iterators it is
using.
- Consider the ByteStringBuilder from SASL
- As potentially more visible ensure clearer method names.
- Ensure adequate javadoc and cross referencing of standards supported.
e.g. If we implement an RFC ensure the number is referenced.
- Testing of each variant
- Consider optional support, e.g. decoding a padded String
- Go beyond testing we can decode what we encode and ensure pre-encoded values can be
handled adequately.
Any other clean up here that seems relevant.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)