Boost.Beast base64 decode

10 Dec 2020

      I'm decoding a Java Web Token, composed of 3 separate base64 encoded parts
(header.payload.signature).

Before I was using Boost.Serialization:

    using namespace boost::archive::iterators;
    using It =
transform_widthstd::string::const_iterator, 8, 6>;
    std::string tmp(It(std::begin(base64_str)), It(std::end(base64_str)));
    return boost::algorithm::trim_right_copy_if(tmp, [](char c) { return c
== '\0'; });

But since I'm already using Boost.Beast, I thought I'd drop the above
dependency, and use this instead:

    using namespace boost::beast::detail;
    std::string decoded(base64::decoded_size(base64_str.size()), '\0');
    auto rc = base64::decode(decoded.data(), base64_str.data(),
base64_str.size());
    decoded.resize(rc.first);

But turns out some (all?) JWTs do not include the trailing equals that
"proper" base64 should have.
And in that case, Beast's rc.first does not include the last character,
which I can still see in
decoded variable prior to the .resize() in the debugger.

Here's the payload part: eyJwYXNzd29yZCI6IlAiLCJ1c2VybmFtZSI6IlUifQ
What it should decode to: {"password":"P","username":"U"}
What Beast's decode yields: {"password":"P","username":"U"

Is this on purpose? Could Beast's base64::decode() be changed to be more
lenient about the absence of trailing equals from the base64 encoded string?

JWT handling seems like a natural fit within the context of Beast, and
although
this is an implementation detail, it would seem logical for decode() to
cope with that, no?

Thanks, --DD

Dominique Devienne

Richard Hodges

Dominique Devienne

Vinnie Falco

Dominique Devienne

tags

participants (3)