Re: Boost.Beast base64 decode

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-12-10 16:29:16

On Thu, 10 Dec 2020 at 17:10, Dominique Devienne via Boost-users <
boost-users_at_[hidden]> wrote:

> 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_width<binary_from_base64<std::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?
>

Beast's base-64 handling has been written specifically for beast's needs so
handling users' needs is not our primary concern at present.

The interface you are using is in the detail:: namespace, which is by boost
convention, deemed "private" to the implementation. We make no guarantees
that the detail:: API will remain stable or compatible between releases or
patches.

>
> 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?
>

>From your point of view as a user, yes it would seem like a natural fit.

>From our point of view as maintainers of a single-purpose library, it would
not make sense to extend our public API into general-purpose base64
encoding/decoding at this time.

Happy to discuss further if you'd like.

I live in the #beast channel of CppLang Slack https://cppalliance.org/slack/

R

>
> Thanks, --DD
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]