On Thu, 10 Dec 2020 at 17:10, Dominique Devienne via Boost-users <
boost-users@lists.boost.org> 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@lists.boost.org
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
--
Richard Hodges
hodge...@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
